ชั้นเรียนยูทิลิตี้เป็นสิ่งชั่วร้าย? [ปิด]

เห็นกระทู้นี้แล้ว

หากคลาส "ยูทิลิตี้" ชั่วร้ายฉันจะใส่รหัสทั่วไปของฉันได้ที่ไหน

และคิดว่าทำไมคลาสยูทิลิตี้ถึงชั่วร้าย?

สมมติว่าฉันมีโมเดลโดเมนที่ลึกหลายสิบชั้น ฉันต้องการอินสแตนซ์ xml-ify ได้ ฉันสร้างเมธอด toXml บนพาเรนต์หรือไม่ ฉันสร้างคลาสตัวช่วย MyDomainXmlUtility.toXml หรือไม่ นี่เป็นกรณีที่ธุรกิจต้องการครอบคลุมทั้งรูปแบบโดเมนจริง ๆ แล้วเป็นวิธีการอินสแตนซ์หรือไม่ จะเกิดอะไรขึ้นถ้ามีวิธีการเสริมมากมายในฟังก์ชัน xml ของแอปพลิเคชัน?

คลาสยูทิลิตี้ไม่ได้ชั่วร้ายอย่างแน่นอน แต่สามารถละเมิดหลักการที่ประกอบขึ้นด้วยการออกแบบเชิงวัตถุที่ดี ในการออกแบบเชิงวัตถุที่ดีคลาสส่วนใหญ่ควรเป็นตัวแทนของสิ่งเดียวและคุณลักษณะและการดำเนินการทั้งหมด หากคุณกำลังดำเนินการกับสิ่งหนึ่งวิธีการนั้นน่าจะเป็นสมาชิกของสิ่งนั้น

อย่างไรก็ตามมีหลายครั้งที่คุณสามารถใช้คลาสยูทิลิตี้เพื่อจัดกลุ่มวิธีการต่างๆเข้าด้วยกันตัวอย่างเช่นjava.util.Collectionsคลาสที่มียูทิลิตี้จำนวนหนึ่งที่สามารถใช้ได้กับคอลเลกชัน Java ใด ๆ สิ่งเหล่านี้ไม่ได้เจาะจงไปที่คอลเล็กชันประเภทใดประเภทหนึ่ง แต่ใช้อัลกอริทึมที่สามารถใช้กับคอลเล็กชันใดก็ได้

จริงๆแล้วสิ่งที่คุณต้องทำคือคิดเกี่ยวกับการออกแบบของคุณและกำหนดตำแหน่งที่เหมาะสมที่สุดในการวางวิธีการ โดยปกติแล้วจะเป็นการดำเนินการภายในชั้นเรียน อย่างไรก็ตามบางครั้งมันก็เป็นคลาสยูทิลิตี้ อย่างไรก็ตามเมื่อคุณใช้คลาสยูทิลิตี้อย่าเพิ่งโยนเมธอดแบบสุ่มเข้าไปแทนที่จะจัดระเบียบวิธีการตามวัตถุประสงค์และฟังก์ชันการทำงาน

ผมคิดว่าฉันทามติทั่วไปคืออาคารเรียนไม่ได้ชั่วร้ายต่อ se คุณต้องใช้มันอย่างรอบคอบ:

• ออกแบบวิธียูทิลิตี้แบบคงที่ให้ใช้งานได้ทั่วไปและใช้ซ้ำได้ ตรวจสอบให้แน่ใจว่าพวกเขาไร้สัญชาติ กล่าวคือไม่มีตัวแปรคงที่

• หากคุณมีวิธีการยูทิลิตี้มากมายให้แบ่งพาร์ติชั่นเป็นคลาสเพื่อให้นักพัฒนาค้นหาได้ง่าย

• อย่าใช้คลาสยูทิลิตี้ซึ่งเมธอดแบบสแตติกหรืออินสแตนซ์ในคลาสโดเมนจะเป็นทางออกที่ดีกว่า ตัวอย่างเช่นพิจารณาว่าเมธอดในคลาสพื้นฐานนามธรรมหรือคลาสตัวช่วยแบบทันทีจะเป็นทางออกที่ดีกว่าหรือไม่

• สำหรับ Java 8 เป็นต้นไป "วิธีการเริ่มต้น" ในอินเทอร์เฟซอาจเป็นตัวเลือกที่ดีกว่าคลาสยูทิลิตี้ (ดูอินเทอร์เฟซด้วยวิธีการเริ่มต้นเทียบกับคลาสนามธรรมใน Java 8เป็นต้น)

อีกวิธีหนึ่งในการดูคำถามนี้คือสังเกตว่าในคำถามที่ยกมา"ถ้าคลาสยูทิลิตี้" ชั่วร้าย ""เป็นข้อโต้แย้งของฟางแมน เหมือนฉันถาม:

"ถ้าหมูบินได้ควรพกร่มไหม".

ในคำถามข้างต้นฉันไม่ได้บอกว่าหมูบินได้ ... หรือว่าฉันเห็นด้วยกับโจทย์ที่ว่าพวกมันบินได้

ข้อความ"xyz is evil"โดยทั่วไปเป็นอุปกรณ์เกี่ยวกับวาทศิลป์ที่มีจุดมุ่งหมายเพื่อทำให้คุณคิดโดยใช้มุมมองที่รุนแรง พวกเขามักไม่ค่อย (ถ้าเคย) ตั้งใจให้เป็นข้อความที่แสดงถึงข้อเท็จจริงตามตัวอักษร

ชั้นเรียนยูทิลิตี้มีปัญหาเนื่องจากไม่สามารถจัดกลุ่มความรับผิดชอบกับข้อมูลที่สนับสนุนได้

อย่างไรก็ตามพวกมันมีประโยชน์อย่างยิ่งและฉันสร้างมันตลอดเวลาเป็นโครงสร้างถาวรหรือเป็นสเต็ปสโตนในระหว่างการปรับโครงสร้างใหม่ให้ละเอียดยิ่งขึ้น

จากคลาสยูทิลิตี้มุมมองClean Codeละเมิดความรับผิดชอบเดียวและหลักการเปิด - ปิด พวกเขามีเหตุผลมากมายในการเปลี่ยนแปลงและเนื่องจากการออกแบบไม่สามารถขยายได้ จริงๆแล้วควรมีอยู่ในระหว่างการปรับโครงสร้างใหม่เป็นแกนกลางเท่านั้น

ฉันคิดว่ามันเริ่มกลายเป็นความชั่วร้ายเมื่อ

1) มีขนาดใหญ่เกินไป (เพียงจัดกลุ่มให้เป็นหมวดหมู่ที่มีความหมายในกรณีนี้)
2) มีวิธีการที่ไม่ควรเป็นวิธีการคงที่

แต่ตราบใดที่ไม่ตรงตามเงื่อนไขเหล่านี้ฉันคิดว่ามันมีประโยชน์มาก

หลักการง่ายๆ

คุณสามารถมองปัญหานี้ได้จากสองมุมมอง:

• *Utilวิธีการโดยรวมมักเป็นข้อเสนอแนะของการออกแบบโค้ดที่ไม่ดีหรือหลักการตั้งชื่อที่ขี้เกียจ
• เป็นโซลูชันการออกแบบที่ถูกต้องสำหรับฟังก์ชันการทำงานแบบไร้สัญชาติข้ามโดเมนที่สามารถนำกลับมาใช้ใหม่ได้ โปรดทราบว่าสำหรับปัญหาทั่วไปเกือบทั้งหมดมีวิธีแก้ไขอยู่แล้ว

ตัวอย่าง 1. แก้ไขการใช้utilคลาส / โมดูล ตัวอย่างไลบรารีภายนอก

สมมติว่าคุณกำลังเขียนใบสมัครที่จัดการสินเชื่อและบัตรเครดิต ข้อมูลจากโมดูลเหล่านี้เปิดเผยผ่านบริการเว็บในjsonรูปแบบ ในทางทฤษฎีคุณสามารถแปลงวัตถุเป็นสตริงด้วยตนเองซึ่งจะอยู่ในjsonแต่นั่นจะเป็นการสร้างวงล้อใหม่ วิธีแก้ไขที่ถูกต้องจะรวมไว้ในไลบรารีภายนอกของโมดูลทั้งสองที่ใช้ในการแปลงวัตถุ java เป็นรูปแบบที่ต้องการ (ในภาพตัวอย่างที่ฉันแสดงgson )

ตัวอย่างที่ 2. การใช้utilคลาส / โมดูลอย่างถูกต้อง เขียนของคุณเองutilโดยไม่มีข้อแก้ตัวให้กับสมาชิกในทีมคนอื่น ๆ

ในกรณีการใช้งานสมมติว่าเราจำเป็นต้องทำการคำนวณบางอย่างในสองโมดูลของแอปพลิเคชัน แต่ทั้งสองอย่างจำเป็นต้องทราบเมื่อมีวันหยุดราชการในโปแลนด์ ในทางทฤษฎีคุณสามารถทำการคำนวณเหล่านี้ภายในโมดูลได้ แต่จะเป็นการดีกว่าหากแยกฟังก์ชันนี้เพื่อแยกโมดูล

นี่คือรายละเอียดเล็ก ๆ แต่สำคัญ ชั้น / โมดูลที่คุณได้เขียนไม่ได้เรียกว่าแต่HolidayUtil PolishHolidayCalculatorมันเป็นutilคลาส แต่เราสามารถหลีกเลี่ยงคำทั่วไปได้

ชั้นเรียนยูทิลิตี้ไม่ดีเพราะหมายความว่าคุณขี้เกียจเกินไปที่จะคิดชื่อชั้นเรียนให้ดีขึ้น :)

ที่ถูกกล่าวว่าฉันขี้เกียจ บางครั้งคุณแค่ต้องทำงานให้เสร็จและจิตใจของคุณก็ว่างเปล่า .. นั่นคือตอนที่คลาส "ยูทิลิตี้" เริ่มคืบคลานเข้ามา

เมื่อมองย้อนกลับไปที่คำถามนี้ตอนนี้ฉันจะบอกว่าวิธีการขยาย C # ทำลายความต้องการคลาสยูทิลิตี้โดยสิ้นเชิง แต่ไม่ใช่ทุกภาษาที่มีโครงสร้างอัจฉริยะเช่นนี้

คุณยังมี JavaScript ซึ่งคุณสามารถเพิ่มฟังก์ชันใหม่ลงในวัตถุที่มีอยู่ได้

แต่ฉันไม่แน่ใจว่ามีวิธีที่ดีในการแก้ปัญหานี้ในภาษาเก่าเช่น C ++ จริงๆ ...

รหัส OO ที่ดีนั้นเขียนยากและหาได้ยากเนื่องจากการเขียน Good OO ต้องใช้เวลา / ความรู้มากกว่าการเขียนโค้ดที่ใช้งานได้ดี

และเมื่อคุณมีงบ จำกัด เจ้านายของคุณมักไม่พอใจที่เห็นว่าคุณใช้เวลาทั้งวันในการเขียนชั้นเรียนมากมาย ...

ฉันไม่เห็นด้วยว่าคลาสยูทิลิตี้นั้นชั่วร้าย

แม้ว่าคลาสยูทิลิตี้อาจละเมิดหลักการ OO ในบางวิธี แต่ก็ไม่ได้เลวร้ายเสมอไป

ตัวอย่างเช่นสมมติว่าคุณต้องการฟังก์ชันที่จะล้างสตริงของค่าที่ตรงกันของสตริงย่อยทั้งหมด xตัวอย่างเช่นสมมติว่าคุณต้องการฟังก์ชั่นที่จะทำความสะอาดสตริงของทุกค่าสตริงจับคู่

stl c ++ (ณ ตอนนี้) ไม่รองรับสิ่งนี้โดยตรง

คุณสามารถสร้างส่วนขยายความหลากหลายของ std::string .

แต่ปัญหาคือคุณต้องการให้ทุกสตริงที่คุณใช้ในโปรเจ็กต์เป็นคลาสสตริงแบบขยายหรือไม่?

มีหลายครั้งที่ OO ไม่สมเหตุสมผลและนี่ก็เป็นหนึ่งในนั้น เราต้องการให้โปรแกรมของเราเข้ากันได้กับโปรแกรมอื่น ๆ ดังนั้นเราจะติดstd::stringและสร้างคลาสขึ้นมาStringUtil_ (หรือบางอย่าง)

ฉันว่าจะดีที่สุดถ้าคุณใช้หนึ่งยูทิลต่อคลาส ฉันว่ามันโง่มากที่มียูทิลิตี้เดียวสำหรับทุกคลาสหรือหลายยูทิลิตี้สำหรับคลาสเดียว

เป็นเรื่องง่ายมากที่จะสร้างแบรนด์ให้เป็นยูทิลิตี้เพียงเพราะผู้ออกแบบไม่สามารถนึกถึงตำแหน่งที่เหมาะสมในการใส่โค้ด มักจะมี "สาธารณูปโภค" ที่แท้จริงน้อย

ตามหลักการทั่วไปแล้วฉันมักจะเก็บรหัสไว้ในแพ็คเกจที่ใช้ครั้งแรกจากนั้นจะทำการ refactor เป็นสถานที่ทั่วไปมากขึ้นเท่านั้นหากฉันพบว่าในภายหลังจำเป็นต้องใช้ที่อื่นจริงๆ ข้อยกเว้นเพียงอย่างเดียวคือหากฉันมีแพ็กเกจที่ทำงานคล้ายกัน / เกี่ยวข้องกันอยู่แล้วและรหัสนั้นเหมาะสมที่สุด

คลาสยูทิลิตี้ที่มีวิธีการคงที่แบบไม่ระบุสถานะจะมีประโยชน์ สิ่งเหล่านี้มักจะง่ายมากในการทดสอบหน่วย

ด้วย Java 8 คุณสามารถใช้วิธีการแบบคงที่ในอินเทอร์เฟซ ... แก้ไขปัญหาได้

ชั้นเรียน Util ส่วนใหญ่ไม่ดีเนื่องจาก:

1. พวกเขาขยายขอบเขตของวิธีการ พวกเขาทำให้รหัสเป็นสาธารณะที่อาจเป็นส่วนตัว หากผู้โทรหลายคนต้องการวิธีการใช้งานในคลาสที่แยกจากกันและมีความเสถียร (เช่นไม่จำเป็นต้องอัปเดต) ในความคิดของฉันควรคัดลอกและวางวิธีการผู้ช่วยส่วนตัวลงในคลาสการโทร เมื่อคุณแสดงเป็น API แล้วคุณจะทำความเข้าใจได้ยากขึ้นว่าจุดเข้าสาธารณะไปยังส่วนประกอบของ jar คืออะไร (คุณรักษาโครงสร้างแบบต้นไม้ที่เรียกว่าลำดับชั้นโดยมีพาเรนต์เดียวต่อหนึ่งวิธีการนี้จะง่ายกว่าในการแยกทางจิตใจออกเป็นส่วนประกอบซึ่งยากกว่าเมื่อ คุณมีเมธอดที่เรียกจากเมธอดหลักหลายวิธี)
2. ส่งผลให้รหัสตาย วิธีการใช้งานเมื่อเวลาผ่านไปจะไม่ได้ใช้งานเมื่อแอปของคุณพัฒนาขึ้นและคุณจะพบกับโค้ดที่ไม่ได้ใช้ซึ่งทำให้ฐานรหัสของคุณเป็นมลพิษ หากยังคงเป็นส่วนตัวคอมไพเลอร์ของคุณจะบอกคุณว่าไม่ได้ใช้วิธีการใดและคุณสามารถลบออกได้ (รหัสที่ดีที่สุดคือไม่มีรหัสเลย) เมื่อคุณทำให้วิธีการดังกล่าวไม่เป็นส่วนตัวคอมพิวเตอร์ของคุณจะไม่มีอำนาจที่จะช่วยคุณลบรหัสที่ไม่ได้ใช้ อาจเรียกได้จากไฟล์ jar อื่นสำหรับคอมพิวเตอร์ทุกคนที่รู้จัก

มีการเปรียบเทียบกับไลบรารีแบบคงที่และแบบไดนามิก

เมื่อฉันไม่สามารถเพิ่มเมธอดในคลาสได้ (กล่าวAccountคือถูกล็อกจากการเปลี่ยนแปลงโดย Jr. Developers) ฉันก็แค่เพิ่มวิธีการคงที่สองสามวิธีในคลาสยูทิลิตี้ของฉันดังนี้:

public static int method01_Account(Object o, String... args) {
    Account acc = (Account)o;
    ...
    return acc.getInt();
}  

คลาสยูทิลิตี้ไม่ได้ชั่วร้ายเสมอไป แต่ควรมีเฉพาะวิธีการที่ใช้กันทั่วไปในฟังก์ชันการทำงานที่หลากหลาย หากมีเมธอดที่ใช้ได้เฉพาะในคลาสจำนวน จำกัด ให้พิจารณาสร้างคลาสนามธรรมในฐานะพาเรนต์ทั่วไปและใส่เมธอดเข้าไป