ชั้นเรียนมีขนาดใหญ่แค่ไหน?

ฉันเป็นนักพัฒนาที่ยาวนาน (ฉันอายุ 49 ปี) แต่ค่อนข้างใหม่สำหรับการพัฒนาเชิงวัตถุ ฉันได้อ่านเกี่ยวกับ OO มาตั้งแต่ไอเฟลของ Bertrand Meyer แต่ได้เขียนโปรแกรม OO น้อยมาก

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

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

จนถึงตอนนี้ดี แต่ในทางกลับกันฉันได้พบผู้เขียนหลายคนที่ให้สูตรเช่น "คลาสควรพอดีในหน้าเดียว" (ฉันจะเพิ่ม "ในขนาดจอภาพอะไร?" ตอนนี้เราพยายามไม่ เพื่อพิมพ์รหัส!)

ยกตัวอย่างเช่นPurchaseOrderคลาสที่มีเครื่องสถานะ จำกัด ควบคุมพฤติกรรมและคอลเลกชันPurchaseOrderItemหนึ่งในข้อโต้แย้งที่นี่ในที่ทำงานคือเราควรใช้PurchaseOrderคลาสที่เรียบง่ายด้วยวิธีการบางอย่าง (น้อยกว่าคลาสข้อมูล) และมีPurchaseOrderFSM“ชั้นผู้เชี่ยวชาญ” ที่จับเครื่องสถานะ จำกัด PurchaseOrderสำหรับ

ฉันจะบอกว่าตกอยู่ในหมวดหมู่ "อิจฉาคุณสมบัติ" หรือ "ความไม่เหมาะสมที่ใกล้ชิด" ของการโพสต์โค้ดของ Jeff Atwood's Smellsเมื่อสยองขวัญการเข้ารหัส ฉันแค่เรียกมันว่าสามัญสำนึก ถ้าผมสามารถออกอนุมัติหรือยกเลิกคำสั่งซื้อของฉันจริงแล้วPurchaseOrderชั้นควรมีissuePO, approvePOและcancelPOวิธีการ

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

นอกจากนี้นั่นไม่ได้ช่วยในการบำรุงรักษาของชั้นเรียนหรือไม่?

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

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

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

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

ฉันไม่คิดว่ามีคำจำกัดความที่เฉพาะเจาะจงของชั้นเรียนที่มีขนาดใหญ่เกินไป อย่างไรก็ตามฉันจะใช้แนวทางต่อไปนี้เพื่อตรวจสอบว่าฉันควร refactor ชั้นเรียนของฉันหรือกำหนดขอบเขตของชั้นเรียนใหม่:

1. มีตัวแปรมากมายที่เป็นอิสระต่อกันหรือไม่? (ความอดทนส่วนบุคคลของฉันประมาณ 10 ~ 20 ในกรณีส่วนใหญ่)
2. มีวิธีการมากมายที่ออกแบบมาสำหรับเคสมุมหรือไม่? (ความอดทนส่วนบุคคลของฉันคือ ... ดีมันขึ้นอยู่กับอารมณ์ของฉันฉันเดา)

ในการไปถึง 1 ลองจินตนาการว่าคุณกำหนดขนาดของคุณกระจกหน้ารถขนาดล้อหางรุ่นหลอดไฟและ 100 รายละเอียดอื่น ๆ carในชั้นเรียนของคุณ แม้ว่าพวกเขาจะทุกคน "ที่เกี่ยวข้อง" carไปที่รถมันเป็นเรื่องยากมากที่จะติดตามพฤติกรรมของชั้นดังกล่าว และเมื่อสักวันหนึ่งเพื่อนร่วมงานของคุณโดยบังเอิญ (หรือในบางกรณีโดยเจตนา) จะเปลี่ยนขนาดของกระจกหน้ารถตามรุ่นของหลอดไฟท้ายคุณจะต้องรู้ว่าทำไมกระจกหน้ารถถึงไม่เหมาะกับรถของคุณอีกต่อไป

ในเรื่องที่เกี่ยวกับ 2 ลองจินตนาการว่าคุณพยายามกำหนดพฤติกรรมทั้งหมดที่รถอาจมีในชั้นเรียนcarแต่car::open_roof()จะมีให้สำหรับรถเปิดประทุนเท่านั้นและcar::open_rear_door()ไม่สามารถใช้ได้กับรถ 2 ประตูเหล่านั้น แม้ว่ารถเปิดประทุนและรถ 2 ประตูเป็น "รถยนต์" ตามคำจำกัดความการใช้มันในชั้นเรียนcarทำให้ชั้นเรียนมีความซับซ้อน ชั้นเรียนนั้นยากต่อการใช้งานและบำรุงรักษายากขึ้น

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

พูดในสิ่งที่คุณต้องการใน 300 บรรทัด

หมายเหตุ: กฎข้อนี้ถือว่าคุณปฏิบัติตามวิธี 'หนึ่งคลาสต่อไฟล์' ซึ่งเป็นแนวคิดของการบำรุงรักษาที่ดี

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

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

ฉันพบว่าฉันกำลังดัดกฎนี้ในโมเดล -> ViewModel -> ดูโลกที่ฉันกำลังสร้าง 'พฤติกรรมวัตถุ' สำหรับหน้า UI เพราะมักใช้เวลามากกว่า 300 บรรทัดเพื่ออธิบายชุดพฤติกรรมที่สมบูรณ์ใน หน้า อย่างไรก็ตามฉันยังใหม่กับรูปแบบการเขียนโปรแกรมนี้และค้นหาวิธีที่ดีในการปรับเปลี่ยนพฤติกรรม / การใช้ซ้ำระหว่างหน้า / viewmodels ซึ่งค่อย ๆ ลดขนาดของ ViewModels ของฉัน

ลองย้อนกลับไปที่:

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

ที่จริงแล้วมันเป็นรากฐานที่สำคัญของการเขียนโปรแกรมซึ่ง OO เป็นเพียงกระบวนทัศน์เดียว

ฉันจะให้แอนทอนเดอแซ็ง - เอกเปเปรีตอบคำถามของคุณ (เพราะฉันขี้เกียจ;)):

ความสมบูรณ์แบบนั้นเกิดขึ้นได้ไม่ใช่เมื่อไม่มีอะไรจะเพิ่มเติมอีกต่อไป แต่เมื่อไม่มีอะไรเหลือให้เอาไป

ยิ่งชั้นเรียนง่ายขึ้นเท่าใดคุณก็จะยิ่งมั่นใจมากขึ้นเท่านั้นและยิ่งทดสอบได้อย่างเต็มที่

ฉันใช้ OP ในการจัดประเภทคุณสมบัติอิจฉา ไม่มีอะไรทำให้ฉันรำคาญยิ่งไปกว่าการมีกลุ่มของชั้นเรียนด้วยวิธีการมากมายที่ใช้งานได้กับผู้ฝึกงานภายในของชั้นเรียนอื่น OO แนะนำให้คุณสร้างแบบจำลองข้อมูลและการดำเนินการกับข้อมูลนั้น ไม่ได้หมายความว่าคุณใส่การดำเนินงานในที่ที่แตกต่างจากข้อมูล! มันพยายามที่จะให้คุณได้รับที่จะนำข้อมูลและวิธีการเหล่านั้นเข้าด้วยกัน

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

ฉันไม่ได้มีคลาสหรือขนาดวิธีที่เหมาะสมที่สุด แต่ฉันชอบที่จะคงวิธีการและฟังก์ชั่นของฉันไว้ในหน้าจอเดียวเพื่อให้ฉันสามารถเห็นความครบถ้วนทั้งหมดในที่เดียว (ฉันได้รับการกำหนดค่าเป็นกลุ่มเพื่อเปิดหน้าต่าง 60 บรรทัดซึ่งเกิดขึ้นใกล้กับจำนวนบรรทัดในหน้าที่พิมพ์ออกมา) มีสถานที่ที่ไม่เหมาะกับการใช้งานมากนัก ฉันชอบที่จะปฏิบัติตามแนวทางเดียวกันสำหรับคำจำกัดความของชั้นเรียนและพยายามทำให้ไฟล์ของฉันมีความยาวไม่เกิน "หน้า" อะไรก็ตามที่มากกว่า 300, 400 บรรทัดจะเริ่มรู้สึกไม่สบายใจ (ส่วนใหญ่เป็นเพราะชั้นเรียนเริ่มรับผิดชอบโดยตรงมากเกินไป)

เมื่อคำจำกัดความของคลาสมีสองร้อยวิธีมันใหญ่เกินไป

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

การออกคำสั่งซื้อมักจะเป็นกระบวนการที่ซับซ้อนที่เกี่ยวข้องมากกว่าเพียงแค่การสั่งซื้อ ในกรณีนี้การรักษาตรรกะทางธุรกิจไว้ในคลาสที่แยกต่างหากและทำให้การสั่งซื้อง่ายขึ้นน่าจะเป็นสิ่งที่ถูกต้อง โดยทั่วไปแล้วคุณพูดถูก - คุณไม่ต้องการคลาส "โครงสร้างข้อมูล" ตัวอย่างเช่นเมธอด "POManager" ระดับธุรกิจของคุณissue()อาจเรียกissue()เมธอดPO PO สามารถกำหนดสถานะเป็น "ออก" และบันทึกวันที่ออกในขณะที่ POManager สามารถส่งการแจ้งเตือนไปยังบัญชีเจ้าหนี้เพื่อแจ้งให้พวกเขาทราบว่าคาดว่าจะได้รับใบแจ้งหนี้และการแจ้งเตือนอื่น ๆ ไปยังคลังโฆษณา วันที่คาดหวัง

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

ฉันพบผู้เขียนหลายคนที่ให้สูตรอาหารเช่น“ คลาสควรพอดีในหน้าเดียว”

ในแง่ของขนาดทางกายภาพของคลาสการเห็นคลาสขนาดใหญ่เป็นการบ่งบอกถึงกลิ่นของรหัส แต่ไม่ได้แปลว่ามีกลิ่นอยู่เสมอ (โดยทั่วไปคือแม้ว่า) ในขณะที่โจรสลัดใน Pirates of Caribbean จะนำไปใช้นี่เป็นสิ่งที่คุณเรียกว่า "แนวทาง" มากกว่ากฎจริง ฉันพยายามอย่างเคร่งครัดติดตาม "ไม่เกินหนึ่งร้อย LOC ในชั้นเรียน" หนึ่งครั้งและผลที่ได้ก็คือวิศวกรรมที่ไม่จำเป็นจำนวนมาก

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

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

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

นอกจากนี้ในตัวอย่างของคุณการเพิ่ม IssuePO, ApprovePO และ Cancel PO ลงในคลาส PurchaseOrder ก็ดูไร้เหตุผล ใบสั่งซื้อจะไม่ออกอนุมัติหรือยกเลิกด้วยตนเอง ถ้า PO ควรมีวิธีการวิธีการนั้นควรจะทำงานในสถานะของมันไม่ได้อยู่ในชั้นเรียนโดยรวม พวกเขาเป็นเพียงคลาสข้อมูล / บันทึกที่คลาสอื่นทำงาน

มีขนาดใหญ่พอที่จะมีตรรกะที่จำเป็นทั้งหมดในการทำงาน

พอขนาดเล็กที่จะบำรุงรักษาและปฏิบัติตามหลักการ Single รับผิดชอบ