ทำไมเราต้องการคลาสจำนวนมากในรูปแบบการออกแบบ

ฉันเป็นนักพัฒนารุ่นน้องในรุ่นพี่และกำลังดิ้นรนมากกับการเข้าใจความคิดเหตุผล

ฉันกำลังอ่านการออกแบบที่ขับเคลื่อนด้วยโดเมน (DDD) และไม่เข้าใจว่าทำไมเราต้องสร้างคลาสจำนวนมาก ถ้าเราทำตามวิธีการออกแบบซอฟต์แวร์เราจะจบด้วยชั้นเรียน 20-30 ชั้นซึ่งสามารถแทนที่ได้ด้วยไฟล์มากที่สุดสองไฟล์และฟังก์ชั่น 3-4 อย่าง ใช่มันอาจยุ่งเหยิง แต่มันสามารถดูแลและอ่านได้มากกว่า

เมื่อใดก็ตามที่ฉันต้องการดูว่าบางอย่างEntityTransformationServiceImplทำอะไรฉันต้องติดตามคลาสอินเทอร์เฟซการเรียกใช้ฟังก์ชันการสร้างการสร้างและอื่น ๆ มากมาย

คณิตศาสตร์ง่าย ๆ :

• รหัสจำลอง 60 บรรทัดเทียบกับ 10 คลาส X 10 (สมมติว่าเรามี logics ที่แตกต่างกันโดยสิ้นเชิง) = 600 บรรทัดของรหัสยุ่งกับ 100 ชั้นเรียน + อีกมากมายที่จะรวมและจัดการ อย่าลืมเพิ่มการฉีดพึ่งพา
• อ่านรหัสยุ่ง 600 เส้น = หนึ่งวัน
• 100 คลาส = หนึ่งสัปดาห์ยังคงลืมว่าหนึ่งจะทำอะไรเมื่อ

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

สมมติว่าถ้าคุณเขียนรหัสยุ่ง 50K LOC ในหนึ่งเดือนสิ่ง DDD ต้องการการตรวจสอบและการเปลี่ยนแปลงมากมาย (ฉันไม่สนใจการทดสอบในทั้งสองกรณี) การเพิ่มหนึ่งอย่างง่ายๆอาจใช้เวลาหนึ่งสัปดาห์หากไม่มากกว่านั้น

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

กรุณาอธิบาย. ทำไมเราต้องการสไตล์ DDD และรูปแบบมากมาย?

UPD 1 : ฉันได้รับคำตอบที่ยอดเยี่ยมมากมายคุณช่วยกรุณาเพิ่มความคิดเห็นได้ไหมหรือแก้ไขคำตอบของคุณพร้อมลิงค์สำหรับอ่านรายการ (ไม่แน่ใจว่าจะเริ่มต้น DDD, รูปแบบการออกแบบ, UML, รหัสเสร็จสมบูรณ์, Refactoring, Pragmatic) .. หนังสือดี ๆ มากมาย) แน่นอนว่ามีการเรียงลำดับดังนั้นฉันจึงสามารถเริ่มทำความเข้าใจและกลายเป็นรุ่นพี่อย่างที่คุณทำ

นี่เป็นปัญหาการเพิ่มประสิทธิภาพ

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

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

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

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

ความซับซ้อนมาจากความสัมพันธ์ไม่ใช่องค์ประกอบ

ฉันสังเกตเห็นจากการวิเคราะห์ของคุณว่าคุณกำลังมองหาปริมาณ - จำนวนรหัสจำนวนชั้นเรียน ฯลฯ ในขณะที่สิ่งเหล่านี้น่าสนใจผลกระทบที่แท้จริงนั้นมาจากความสัมพันธ์ระหว่างองค์ประกอบซึ่งระเบิดแบบ combinatorially ตัวอย่างเช่นถ้าคุณมี 10 ฟังก์ชั่นและไม่มีความคิดที่ขึ้นอยู่กับว่าคุณมี 90 ความสัมพันธ์ที่เป็นไปได้ (การพึ่งพา) คุณต้องกังวล - แต่ละฟังก์ชั่นสิบอาจขึ้นอยู่กับเก้าฟังก์ชั่นอื่น ๆ และ 9 x 10 = 90. คุณอาจไม่ทราบว่าฟังก์ชั่นใดที่แก้ไขตัวแปรหรือวิธีการส่งผ่านข้อมูลดังนั้นผู้เขียนจึงมีหลายสิ่งที่ต้องกังวลเมื่อแก้ไขปัญหาเฉพาะ ในทางตรงกันข้ามถ้าคุณมี 30 คลาส แต่มีการจัดเรียงอย่างชาญฉลาดพวกเขาสามารถมีความสัมพันธ์ได้น้อยถึง 29 ครั้งเช่นถ้าพวกเขามีเลเยอร์หรือจัดเรียงเป็นกอง

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

ก่อนอื่นการอ่านและการบำรุงรักษามักอยู่ในสายตาของคนดู

สิ่งที่คุณสามารถอ่านได้อาจไม่ใช่เพื่อนบ้านของคุณ

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

DDD

อีกวิธีหนึ่งที่ DDD ช่วยทีมนักพัฒนาซอฟต์แวร์คือการแนะนำวิธีการจัดระเบียบแนวคิดและพฤติกรรมรหัสของคุณ การประชุมนี้ทำให้การค้นพบสิ่งต่าง ๆ ง่ายขึ้นและง่ายต่อการบำรุงรักษาแอปพลิเคชัน

• แนวคิดโดเมนถูกเข้ารหัสเป็นเอนทิตีและมวลรวม
• พฤติกรรมโดเมนอยู่ในเอนทิตีหรือบริการโดเมน
• ความแน่นอนจะได้รับการยืนยันโดย Aggregate Roots
• ที่เก็บข้อมูลกังวลถูกจัดการโดยที่เก็บ

ข้อตกลงนี้ไม่ได้อคติง่ายต่อการรักษา อย่างไรก็ตามเป็นเรื่องง่ายที่จะวัดได้เมื่อทุกคนเข้าใจว่าพวกเขากำลังทำงานในบริบท DDD

การเรียนการสอน

เรียนช่วยให้มีการบำรุงรักษา, การอ่าน, การค้นพบ ฯลฯ ... เพราะพวกเขาเป็นที่รู้จักกันดีการประชุม

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

ฉันรู้ว่ามันฟังดูเป็นนามธรรมมาก แต่คุณสามารถคิดแบบนี้ได้:

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

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

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

และเมื่อพิจารณาถึงส่วนประกอบ 30 ชิ้นนั้นอาจครอบคลุมแอพพลิเคชั่น3 ชั้นของคุณคุณอาจจะต้องให้เหตุผลกับส่วนประกอบทั้งหมดประมาณ 10 ชิ้นในแต่ละครั้ง

ดูเหมือนว่าจะจัดการได้ค่อนข้างสวย

สรุป

เป็นหลักสิ่งที่คุณเห็น devs อาวุโสทำคือ:

พวกเขากำลังแยกแอปพลิเคชันออกเป็นเหตุผลง่าย ๆ เกี่ยวกับคลาส

พวกเขากำลังจัดระเบียบสิ่งเหล่านี้ให้เป็นเรื่องง่ายเพื่อให้เหตุผลเกี่ยวกับเลเยอร์

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

โปรดอธิบายฉันว่าทำไมเราถึงต้องการสไตล์ DDD นี้รูปแบบมากมาย?

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

แต่สำหรับคำถามเฉพาะของคุณ: มักจะมีคลาสมากกว่าที่คุณคาดหวัง (a) เนื่องจากมีความพยายามในการจำแนกพฤติกรรมโดเมนจากระบบประปาและ (b) เนื่องจากมีความพยายามพิเศษเพื่อให้มั่นใจว่าแนวคิดนั้น ในรูปแบบโดเมนจะแสดงอย่างชัดเจน

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

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

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

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

ในความเป็นธรรม: บางส่วนเป็นความเสียหายทางสมอง Object Oriented รูปแบบเดิมอธิบายโดย Evans ขึ้นอยู่กับโครงการ Java ที่เขาเข้าร่วมใน 15+ ปีที่ผ่านมา; สถานะและพฤติกรรมนั้นเชื่อมโยงกันอย่างแน่นหนาในลักษณะนั้นซึ่งนำไปสู่ภาวะแทรกซ้อนที่คุณอาจต้องการหลีกเลี่ยง ดูการรับรู้และการกระทำโดย Stuart Halloway หรือInlining Codeของ John Carmack

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

มีจุดดีมากมายในคำตอบอื่น ๆ แต่ฉันคิดว่าพวกเขาพลาดหรือไม่เน้นความผิดพลาดทางแนวคิดที่สำคัญที่คุณทำ:

คุณกำลังเปรียบเทียบความพยายามในการทำความเข้าใจกับโปรแกรมทั้งหมด

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

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

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

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

ผลกระทบที่มีต่อกิจกรรมอื่น ๆ :

• การทดสอบจะง่ายขึ้นด้วยหน่วยที่เล็กลง
• ข้อขัดแย้งในการผสานน้อยลงเนื่องจากโอกาสสำหรับผู้พัฒนาสองคนที่ทำงานบนโค้ดชิ้นเดียวกันนั้นมีขนาดเล็กลง
• การทำสำเนาน้อยลงเพราะง่ายต่อการนำชิ้นส่วนมาใช้ใหม่ (และเพื่อค้นหาชิ้นส่วนได้ตั้งแต่แรก)

เพราะรหัสทดสอบนั้นยากกว่าการเขียนรหัส

คำตอบจำนวนมากได้ให้เหตุผลที่ดีจากมุมมองของนักพัฒนา - การบำรุงรักษานั้นสามารถลดลงได้ในราคาที่ทำให้รหัสมีพลังมากขึ้นในการเขียนตั้งแต่แรก

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

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

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

การแก้ปัญหา: การทดสอบขนาดเล็กจำนวนมากที่ระบุความล้มเหลวที่เฉพาะเจาะจงหนึ่งที่อาจเกิดขึ้น

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

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

อย่างที่ทราบกันดีว่านี่ไม่ได้หมายความว่าผู้คนจะไม่ทำสิ่งที่ "ไกลเกินไป" แต่มีเหตุผลที่ถูกต้องสำหรับการแยกเบสโค้ดออกเป็นส่วนที่เล็กลง / น้อยกว่านั้นคือถ้าทำอย่างสมเหตุสมผล

โปรดอธิบายฉันว่าทำไมเราถึงต้องการสไตล์ DDD นี้รูปแบบมากมาย?

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

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

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

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

เนื่องจากคำถามของคุณครอบคลุมพื้นที่จำนวนมากด้วยสมมติฐานจำนวนมากฉันจะเลือกหัวข้อของคำถามของคุณ:

ทำไมเราต้องการคลาสจำนวนมากในรูปแบบการออกแบบ

พวกเราไม่ทำ. ไม่มีกฎที่ยอมรับโดยทั่วไปที่บอกว่าต้องมีหลายคลาสในรูปแบบการออกแบบ

มีคำแนะนำหลัก ๆ สองข้อสำหรับการตัดสินใจว่าจะวางรหัสไว้ที่ใดและจะตัดงานของคุณเป็นหน่วยต่าง ๆ ของรหัสได้อย่างไร:

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

ทำไมทั้งสองควรมีความสำคัญ

• การติดต่อกัน: วิธีการที่ทำสิ่งต่าง ๆ มากมาย (เช่นสคริปต์ CGI ที่ล้าสมัยที่ทำ GUI, ตรรกะ, การเข้าถึงฐานข้อมูล ฯลฯ ทั้งหมดในระเบียบรหัสยาว) กลายเป็นเรื่องที่ไม่สะดวก ในช่วงเวลาของการเขียนมันเป็นที่ดึงดูดเพียงแค่ใส่ความคิดของคุณเป็นวิธีที่ยาว งานนี้มันเป็นเรื่องง่ายที่จะนำเสนอและเช่นนั้นและคุณสามารถทำได้ด้วย ปัญหาเกิดขึ้นภายหลัง: หลังจากไม่กี่เดือนคุณอาจลืมสิ่งที่คุณทำ บรรทัดของรหัสที่ด้านบนอาจอยู่ห่างออกไปสองสามหน้าจอจากบรรทัดด้านล่าง มันง่ายที่จะลืมรายละเอียดทั้งหมด การเปลี่ยนแปลงใด ๆ ในวิธีการอาจทำลายพฤติกรรมใด ๆ ของสิ่งที่ซับซ้อน มันจะค่อนข้างยุ่งยากในการปรับโครงสร้างหรือนำชิ้นส่วนกลับมาใช้ใหม่ของวิธีการ และอื่น ๆ
• การมีเพศสัมพันธ์: เมื่อใดก็ตามที่คุณเปลี่ยนหน่วยของรหัสคุณอาจแตกหน่วยอื่น ๆ ทั้งหมดที่ขึ้นอยู่กับมัน ในภาษาที่เข้มงวดเช่น Java คุณอาจได้รับคำแนะนำในช่วงเวลารวบรวม (เช่นเกี่ยวกับพารามิเตอร์การประกาศข้อยกเว้นและอื่น ๆ ) แต่การเปลี่ยนแปลงจำนวนมากไม่ได้ทำให้เกิดการเปลี่ยนแปลง (เช่นการเปลี่ยนแปลงพฤติกรรม) และภาษาอื่น ๆ ที่มีพลวัตมากขึ้นไม่มีความเป็นไปได้ดังกล่าว ยิ่งคลัปยิ่งสูงเท่าไหร่ยิ่งมีการเปลี่ยนแปลงอะไรมากขึ้นและคุณอาจจะต้องหยุดชะงักเมื่อจำเป็นต้องเขียนใหม่ทั้งหมดเพื่อให้บรรลุเป้าหมาย

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

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

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

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

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

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

ผู้เขียนที่มีประสบการณ์ได้เรียนรู้:

• เนื่องจากโปรแกรมขนาดเล็กและ clasess เริ่มเติบโตโดยเฉพาะอย่างยิ่งโปรแกรมที่ประสบความสำเร็จ รูปแบบที่เรียบง่ายที่ทำงานในระดับง่ายไม่ได้ปรับขนาด
• เพราะมันอาจดูเป็นภาระที่ต้องเพิ่ม / เปลี่ยนสิ่งประดิษฐ์หลายอย่างสำหรับทุก ๆ การเพิ่ม / เปลี่ยน แต่คุณรู้ว่าต้องเพิ่มอะไรและมันง่ายที่จะทำ 3 นาทีในการพิมพ์เต้น 3 ชั่วโมงของการเข้ารหัสที่ชาญฉลาด
• ชั้นเรียนขนาดเล็กจำนวนมากไม่ "ยุ่ง" เพียงเพราะคุณไม่เข้าใจว่าทำไมค่าใช้จ่ายจึงเป็นความคิดที่ดี
• หากไม่มีการเพิ่มความรู้ในโดเมนรหัส 'ชัดเจนสำหรับฉัน' มักจะเป็นปริศนาสำหรับเพื่อนร่วมทีมของฉัน ... บวกกับอนาคตของฉัน
• ความรู้เกี่ยวกับเผ่าสามารถทำให้โครงการยากที่จะเพิ่มสมาชิกในทีมอย่างง่ายดายและยากสำหรับพวกเขาที่จะมีประสิทธิผลอย่างรวดเร็ว
• การตั้งชื่อเป็นหนึ่งในสองปัญหาที่หนักหนาในการคำนวณยังคงเป็นความจริงและคลาสและวิธีการมากมายมักเป็นแบบฝึกหัดที่เข้มข้นในการตั้งชื่อซึ่งหลายคนคิดว่าเป็นประโยชน์อย่างมาก

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

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

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

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

มีหลายคลาสที่ช่วยระบุว่าเป็นงานพื้นฐานและสามารถเรียกชั้นเรียนได้ตลอดเวลา

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