รูปแบบการออกแบบใดที่เลวร้ายที่สุดหรือมีการ จำกัด แคบที่สุด? [ปิด]

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

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

คุณใช้รูปแบบการออกแบบแบบไหนที่ทำให้คุณกลับมาโดยรวม? รูปแบบการออกแบบใดที่เลวร้ายที่สุดรูปแบบที่คุณควรพิจารณายกเว้นในสถานการณ์เดียวที่มีเหตุผล (อ่าน: รูปแบบการออกแบบใดที่นิยามไว้แคบมาก) (มันเหมือนกับว่าฉันกำลังมองหารีวิวเชิงลบของผลิตภัณฑ์ที่ดีโดยรวมของ Amazon เพื่อดูว่าคนที่ถูกหลอกลวงมากที่สุดในการใช้รูปแบบการออกแบบ) และฉันไม่ได้พูดถึง Anti-Patterns ที่นี่ แต่เกี่ยวกับรูปแบบที่มักจะคิดว่าเป็น รูปแบบ "ดี"

แก้ไข:ตามที่บางคนตอบปัญหาส่วนใหญ่มักจะมีรูปแบบที่ไม่ "ไม่ดี" แต่ "ใช้ผิด" หากคุณรู้จักรูปแบบที่มักใช้ในทางที่ผิดหรือยากต่อการใช้

ฉันไม่เชื่อในรูปแบบที่ไม่ดีฉันเชื่อว่ารูปแบบสามารถใช้ได้ไม่ดี!

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

สำหรับคำตอบนี้ฉันพิจารณาเฉพาะรูปแบบ GOF ฉันไม่รู้รูปแบบที่เป็นไปได้ทั้งหมดดีพอที่จะนำมาพิจารณาด้วย

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

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

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

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

คนอื่น ๆ ได้แสดงความคล้ายคลึงกับความเกลียดชังส่วนตัวของซิงเกิลของฉันแล้วดังนั้นฉันจะไม่ขยายตัวที่นี่

ซิงเกิล มันอยู่ในรูปแบบ GOF ซึ่งตอนนี้เรียกว่า anti-pattern บ่อยขึ้น สาเหตุหนึ่งที่ทำให้ Singleton ทำให้โค้ดทดสอบยากขึ้น

หากคุณรู้จักรูปแบบที่มักใช้ในทางที่ผิดหรือยากต่อการใช้

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

และแน่นอนว่า MVVM นั้นยากเหมือนนรกและไม่คุ้มกับโครงการระยะสั้นขนาดเล็ก

Dr. WPF โพสต์แดกดันเกี่ยวกับเรื่องนี้ในบทความMV-poo ของเขา

รูปแบบบางอย่างในหนังสือ GOF เป็นภาษา C ++ โดยเฉพาะในแง่ที่ว่ามันใช้น้อยกว่าในภาษาที่มีการสะท้อนเช่นรูปแบบต้นแบบมีความสำคัญน้อยกว่าใน Java

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

คนที่ฉันเสียใจบ่อยที่สุด (แม้ว่าจะไม่ได้โกรธมากที่สุด): เมื่อฉันควรจะสร้างฟังก์ชั่น แต่ฉันใช้วิธีการแก้ปัญหาของ OOP

โรงงาน.ฉันเคยเห็นโค้ดใช้มันเพื่อสร้างประเภทเดียว นั่นคือรหัส IMO ที่ไร้ประโยชน์อย่างสมบูรณ์ มันไม่ได้ช่วยให้ตัวอย่างมากมายทางออนไลน์มีการวางแผนอย่างสมบูรณ์ โรงงานพิซซ่า

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

ซิงเกิล

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

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

ฉันมักจะชอบที่จะใช้หนึ่งเดียวและมี "Wannabe" singletons "สมัครสมาชิก" อื่น ๆ ทั้งหมดของคุณ การใช้ซิงเกิลที่พบบ่อยที่สุดของฉันคือการจัดการ "shout event": คุณเพียงแค่ "แพร่ภาพไปทั่วโลก" ที่มีเหตุการณ์เกิดขึ้นและทุกคนที่รับฟังการจัดการเหตุการณ์จะทำ ด้วยวิธีนี้คุณแยกกิจกรรมที่เกิดขึ้นจริงกับสิ่งที่ฟังพวกเขา (การบันทึกสัญญาณ ฯลฯ )

ผู้มาเยือน

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

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

(หมายเหตุ: คุณไม่ควรสับสนกับสถาปัตยกรรมมุมมองเอกสารซึ่งเป็นรูปแบบที่แตกต่างกันเล็กน้อย)

ฉันคิดว่าปัญหาของรูปแบบที่ซับซ้อนมากขึ้นคือมีรูปแบบมากมายที่พวกเขาสูญเสียคุณค่าเป็นอุปกรณ์สื่อสาร

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

ไม่มีรูปแบบไม่ดีเท่านั้นคนเลว

ฉันชอบที่จะสืบทอดรหัสที่อ่านได้ง่ายว่าทำอะไรบางอย่างที่ชัดเจน แต่อย่างละเอียดเล็ก ๆ น้อย ๆ หรือไม่ (คิวชั่วโกงดนตรี) ใหม่ใช้งาน (หอบ!) InheritAbstractTemplateFaucetSink<Kitchen>กว่าบางคลุกเคล้าอยู่อาศัยของ

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

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

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

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

" มีสองวิธีในการสร้างการออกแบบซอฟต์แวร์: วิธีหนึ่งคือทำให้ง่ายจนไม่มีข้อบกพร่องและอีกวิธีหนึ่งคือทำให้มันซับซ้อนจนไม่มีข้อบกพร่องชัดเจนวิธีแรกยากกว่ามาก . "

• Tony Hoare (ผู้ประดิษฐ์ของ quicksort บิดาแห่งการออกแบบระบบปฏิบัติการที่ทันสมัยผู้สร้างตรรกะ Hoare และผู้รับรางวัลทัวริง)

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