เป็นเรื่องปกติหรือไม่ที่จะใช้คลาสบางส่วนเพื่อให้ได้ 'แบบแยกส่วนย่อย'?

ฉันเพิ่งพบสถานการณ์ใน codebase ของเราที่ทีมอื่นสร้าง 'god class' ที่มีประมาณ 800 วิธีแบ่งเป็น 135 ไฟล์เป็นคลาสบางส่วน

ฉันถามทีมอื่นเกี่ยวกับเรื่องนี้ ในขณะที่ปฏิกิริยาทางเดินอาหารของฉันคือการทำให้มันออกมาจากวงโคจรพวกเขายืนยันว่ามันเป็นการออกแบบที่ดีการใช้งานทั่วไปและมันส่งเสริม 'modularity' และ 'ความง่ายในการใช้งาน' เพราะนักพัฒนาใหม่สามารถใส่กลอนในการทำงานได้ ของระบบ

นี่เป็นเรื่องธรรมดาหรือเป็นความคิดที่ดีหรือไม่? ฉันอยากจะทำตามขั้นตอนทันทีเพื่อทำให้สัตว์ร้ายนี้ (หรืออย่างน้อยก็ป้องกันไม่ให้มันเติบโตต่อไป) แต่ฉันก็เต็มใจที่จะเชื่อว่าฉันผิด

นี่ไม่ใช่ความคิดที่ดีเลย

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

ดูมันด้วยวิธีนี้: ถ้าคลาสพระเจ้าที่มี 800 วิธีในหนึ่งไฟล์ที่คุณรู้ว่าทุกอย่างอยู่ที่ไหนเป็นสิ่งที่ไม่ดี - และฉันคิดว่าทุกคนจะเห็นด้วยว่ามันคืออะไร - แล้วคลาสเทพก็จะมี 800 วิธีได้อย่างไร แผ่กระจายไปทั่ว 135 ไฟล์ที่คุณไม่ทราบว่าทุกอย่างเป็นสิ่งที่ดี

ดังนั้นคำถามคือ:

นี่เป็นเรื่องธรรมดาหรือเป็นความคิดที่ดีหรือไม่?

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

อย่างไรก็ตามคำถามนั้นเป็นปลาเฮอริ่งแดงไปยังส่วนที่สำคัญจริงสิ่งที่พลาด; เนื่องจาก OP ยังมีสิ่งต่อไปนี้ที่จะพูดเกี่ยวกับสถานการณ์:

(... ) ในขณะที่ปฏิกิริยาทางเดินอาหารของฉันคือการทำให้มันออกมาจากวงโคจรพวกเขายืนยัน ...

(... ) ฉันมีแนวโน้มที่จะทำตามขั้นตอนทันทีเพื่อทำให้สัตว์ร้ายนี้ (หรืออย่างน้อยก็ป้องกันไม่ให้มันเติบโตต่อไป) แต่ฉันก็เต็มใจที่จะเชื่อว่าฉันผิด

ถือม้าของคุณ!

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

ฉันเคยอยู่ในสถานการณ์ที่คล้ายคลึงกันและให้ฉันบอกคุณ: ไม่ตกสำหรับการกระตุ้นให้ทำเช่นนั้น แน่นอนว่าคุณสามารถทิ้ง Nuke Hammer of Justice ไว้ในทีม แต่ก่อนที่คุณจะทำเช่นนั้นโปรดสร้างอารมณ์ขันให้คุณด้วยปริศนาต่อไปนี้:

จะเกิดอะไรขึ้นถ้าคุณบอกทีมที่รหัสของพวกเขาดูดและSOD ปิด ?

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

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

ใส่ตัวเองไว้ในรองเท้าพวกเขาจะทำอะไร? ฉันขอให้คุณสนุกกับผลลัพธ์ที่เป็นไปได้ดังต่อไปนี้:

สมาชิกทีม # 1: "มีผู้ชายคนนี้บอกเราว่าเราทำผิดไปหลายปีแล้ว"

สมาชิกทีม # 2 และ # 3: "อะไรที่ฉุดกระชาก"

สมาชิกในทีมผู้มีอิทธิพล # 4: "ไม่ต้องกังวลกับมันฉันจะไปหาผู้บริหารและรายงานว่าเป็นการก่อกวน"

ดูว่ามีสมาชิกในทีมที่มีอิทธิพล # 4 ? เขาไปที่ฝ่ายบริหารและลดกรรมของคุณใน บริษัท เขาอาจเป็นคนอเมริกันเชื้อสายอิตาลีบอกให้ทุกคนไม่ต้องกังวลกับเรื่องนี้ แต่ฉันจะเหยียดสีผิว

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

แม้ว่าคุณจะจัดการให้คนจำนวนมากออกจากระบบนี้เพื่อ "สอนบทเรียนให้ทีม" โปรดจำไว้ว่าคุณกำลังทำสิ่งนี้กับผู้ที่ฉลาดหลักแหลมซึ่งเห็นได้ชัดว่าทำอะไรบางอย่างเสร็จ เมื่อรหัสจะถูกเขียนใหม่ / refactored / จัดการ / whatever'd ด้วยและปัญหาที่เกิดขึ้นว่าคุณจะต้องรับผิดชอบตามที่คุณได้ Firestarter

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

มีวิธีอื่น ๆ (ผู้ใหญ่มาก)

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

• The Uninformed - พวกเขาไม่รู้จริง ๆ ว่ามีวิธีอื่นหรือไม่เข้าใจ นักพัฒนารุ่นเยาว์มักจะพอดีกับหมวดหมู่นี้ แต่ไม่จำเป็น (พูดตามตรง: ฉันได้พบกับนักพัฒนารุ่นน้องที่จะมีความสว่างมากกว่านี้)
• The ฝูง - พวกเขารู้เทคนิคที่ดีกว่าการใช้คลาสบางส่วน แต่ไม่ทราบว่าพวกเขาได้รับอนุญาต
• The Cynic - พวกเขาชอบที่จะโต้แย้งว่าการมีชั้นเรียนบางส่วนนั้นดีกว่าความคิดของคุณเพียงเพื่อการโต้แย้ง มันง่ายที่จะทำในฝูงชนแทนที่จะยืนต่อหน้าฝูงชน
• The Burned - ด้วยเหตุผลแปลก ๆ พวกเขาไม่ชอบที่จะสร้างคลาสใหม่มีแนวโน้มที่พวกเขาจะเข้าใจว่ามันยากเกินไป
• The Time Crunched - พวกเขายุ่งมากจนไม่สามารถแก้ไขรหัสได้
• The Boss - พวกเขาคิดว่า: "มันใช้งานได้ดี
• ไร้เหตุผล - โอเคพวกมันบ้าไปหมดแล้ว

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

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

• ชั้นเทพของพวกเขากำลังทำอะไรกันแน่?
• พวกเขาเจอปัญหาอะไรบ้างไหม? พวกเขามีข้อบกพร่องหรือไม่? แนะนำการแก้ไขที่มีสติโดยไม่บอกให้ทำเช่นนั้น
• หากคุณเป็นผู้ใช้ god class นี้ในฐานะ API: มีวิธีที่ง่ายกว่าในการใช้รหัสมากกว่าใช้ทั้งหมดหรือไม่? แนะนำตัวอย่างที่ง่ายกว่าดูว่ามันตอบสนองอย่างไร
• คุณสามารถสลับการใช้งานบางฟังก์ชั่นอื่นโดยไม่ต้องเขียนฟังก์ชั่นได้หรือไม่?
• พวกเขาต้องการการฝึกอบรมบ้างไหม? คุณสามารถโน้มน้าวผู้บริหารให้ทำแบบนั้นหรือมีการประชุมอาหารกลางวันเกี่ยวกับรูปแบบและวิธีปฏิบัติ

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

หน้าคลาสและวิธีการบางส่วนของ MSDN แนะนำสองสถานการณ์สำหรับการใช้คลาสบางส่วน:
1. การแบ่งคลาสยักษ์ออกเป็นหลายไฟล์แยกกัน
2. ในการมีที่ให้ใส่ซอร์สโค้ดที่สร้างขึ้นอัตโนมัติ

2 ถูกใช้อย่างหนักโดย Visual Studio (เช่นสำหรับไฟล์ aspx และสำหรับ winforms) นี่เป็นการใช้คลาสที่สมเหตุสมผลบางส่วน

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

แม้ว่าคุณจะสามารถแบ่งชั้นเรียนอย่างชาญฉลาดเป็นไฟล์แยกต่างหากสำหรับผู้ใช้ที่แตกต่างกัน แต่คุณไม่สามารถแยกชั้นเรียนออกเป็นชั้นเรียนอื่นแทนได้หรือไม่

ดังนั้นในที่สุดพวกเขากำลังทำการพัฒนาตามขั้นตอนปกติโดยไม่ต้องมี OOP ใด ๆ พวกมันมีเนมสเปซส่วนกลางเดียวที่มีเมธอดตัวแปรและอะไรทั้งหมด

ชักชวนพวกเขาว่าพวกเขาทำผิดหรือเอานรกออกไปจากที่นั่น

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

เพียงเพราะคุณมีคลาสยูทิลิตี้หนึ่งไม่ได้หมายความว่าคุณไม่สามารถมีคลาสยูทิลิตี้อื่น

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

และไม่ใช่สิ่งนี้ไม่ใช่เรื่องปกติ (จำนวนไฟล์มากกว่าจำนวนฟังก์ชั่นฟรี)

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

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

ฉันไม่แน่ใจว่าทุกคนสามารถดูแลรักษาได้อย่างง่ายดายโดยไม่ต้องศึกษา ตอนนี้ถ้าคุณฆ่ามันจำนวนวิธีการจะไม่ลดลง สำหรับฉันวิธีการและความซับซ้อนนั้นเป็นปัญหาที่แท้จริง หากวิธีการเป็นของคลาสจริง ๆ แล้วการมี 1 ไฟล์ขนาดใหญ่จะไม่ทำให้ชีวิตของคุณง่ายขึ้นโดยเฉพาะอย่างยิ่งในการบำรุงรักษาจริง ๆ แล้วมันอาจจะมีข้อผิดพลาดมากกว่าที่จะเปิดเผยรหัสนี้ทั้งหมดสำหรับข้อผิดพลาดโง่ ๆ และแทนที่

ดังนั้นควรระมัดระวังและปรับการตัดสินใจฆ่า นอกจากนี้ให้พิจารณาว่าจะต้องทำการทดสอบใด

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

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