ดังนั้น“ รูปแบบการออกแบบที่ขาดคุณสมบัติทางภาษา” หรือไม่ [ปิด]

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

PaulGraham กล่าวว่า "Peter Norvig พบว่า 16 จาก 23 รูปแบบในรูปแบบการออกแบบนั้น 'มองไม่เห็นหรือเรียบง่าย' ใน Lisp"

หรือประโยคอื่นที่ยืนยันสิ่งที่ฉันเห็นเมื่อเร็ว ๆ นี้กับผู้ที่พยายามจำลองชั้นเรียนใน JavaScript:

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

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

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

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

ฉันไม่ได้ตระหนักถึงการอภิปรายหรือการศึกษาเชิงลึกใด ๆ ที่คำนึงถึงสิ่งเหล่านี้ทั้งหมด

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

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

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

แก้ไข:

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

แก้ไข 2 - เพิ่มตัวนับ AbstractSingletonProxyFactoryBean เพื่อเพิ่มความสนุกในรูปแบบ เพื่อความเป็นธรรมโดยสมบูรณ์เมื่อดูจากแสง AOP แม้แต่ตัวอย่างเคาน์เตอร์ก็สามารถป้องกันได้