คุณจะหลีกเลี่ยงการวนซ้ำอย่างไม่สิ้นสุดผ่านการออกแบบที่ดีที่สุดที่เท่ากันได้อย่างไร

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

ตัวอย่าง:

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

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

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

จากนั้นฉันอาจลองวิธีอื่น แต่ก็มีปัญหามากมายเช่นกัน จากนั้นคนต่อไปและอีกคนหนึ่งหลังจาก ฯลฯ

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

แก้ไข: ดูเหมือนจะมีการตีความจำนวนหนึ่งของคำถามที่ฉันต้องการล้าง:

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

เมื่อฉันได้รับการตัดสินใจที่ยากลำบากเช่นนั้นฉันมักถามตัวเองด้วยคำถามสามข้อ:

1. ข้อดีและข้อเสียของโซลูชั่นที่มีทั้งหมดคืออะไร

2. มีวิธีแก้ปัญหาฉันยังไม่ได้พิจารณาหรือไม่?

3. สิ่งสำคัญที่สุดคือ:
   ความต้องการของฉันคืออะไร? ไม่ใช่ข้อกำหนดบนกระดาษ แต่เป็นสิ่งพื้นฐานที่แท้จริงใช่ไหม
   ฉันสามารถจัดรูปแบบปัญหาใหม่ / ปรับแต่งความต้องการของมันเพื่อให้สามารถแก้ปัญหาที่เรียบง่ายและตรงไปตรงมาได้หรือไม่?
   ฉันสามารถแสดงข้อมูลของฉันในวิธีที่ต่างกันได้หรือไม่เพื่อให้สามารถใช้วิธีการแก้ปัญหาที่เรียบง่าย

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

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

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

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

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

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

ตอนนี้ถึงเนื้อของสิ่งต่าง ๆ :

สิ่งนี้ยากมากเมื่อแต่ละวิธีดูเหมือนจะมีปัญหามากเท่ากับปัญหาอื่น ๆ

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

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

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

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

สิ่งนี้ส่งผลให้เกิดการสูญเสียแรงจูงใจเพราะรหัส "สะอาด" ไม่ได้เป็นตัวเลือกในบางครั้ง

สมบูรณ์แบบเป็นศัตรูของความดี ทำให้บางสิ่งบางอย่างทำงานได้จากนั้นปรับโครงสร้างใหม่

มีวิธีการออกแบบที่สามารถช่วยลดปัญหานี้ได้หรือไม่? มีวิธีปฏิบัติที่ยอมรับได้สำหรับสิ่งที่ควรทำในสถานการณ์เช่นนี้หรือไม่?

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

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

มันเหมือนกับการพยายามสร้างรถที่เริ่มต้นด้วยยาง

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

โมดูลจะมีลักษณะอย่างไรถ้าคุณจะออกแบบและนำไปใช้ตั้งแต่เริ่มต้น? ไกลแค่ไหนจาก "อุดมคติ" คือการใช้งานปัจจุบันของคุณ

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

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

คำแนะนำที่ดีที่สุดที่ฉันสามารถให้สำหรับสถานการณ์นี้คือ:

• ไม่พยายามที่จะบรรลุเป้าหมายหลักของคุณในหนึ่งใน "บิ๊กแบง" ,

• เรียนรู้วิธีปรับปรุงโค้ดของคุณในขั้นตอนเล็ก ๆ !

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

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

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

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

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

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

• การสร้างใหม่โดย Fowler: อธิบายแคตตาล็อกของการรีแฟคเตอร์ขนาดเล็กมาก

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

บางครั้งหลักการออกแบบที่ดีที่สุดสองข้อคือ KISS * และ YAGNI ** อย่ารู้สึกว่าต้องยัดเยียดลวดลายการออกแบบที่รู้จักในโปรแกรมที่ต้องพิมพ์ "Hello world!"

 * Keep It Simple, Stupid
 ** You Ain't Gonna Need It

แก้ไขหลังจากอัปเดตคำถาม (และสะท้อนสิ่งที่ Pieter B พูดได้ในระดับหนึ่ง):

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

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

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

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

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

ดังนั้น TL; DR: หยุดพักอย่าบังคับให้ขอความช่วยเหลือ