Gang of Four สำรวจ“ Pattern Space” หรือไม่?

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

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

มันไม่ได้เกิดขึ้น มากกว่า 20 ปีหลังจากหนังสือ GoF ออกมามีเพียง 12 รูปแบบเพิ่มเติมที่ปรากฏในบทความ Wikipedia ซึ่งส่วนใหญ่เป็นที่นิยมน้อยกว่าต้นฉบับมาก (ฉันไม่ได้รวมรูปแบบการทำงานพร้อมกันที่นี่เพราะครอบคลุมหัวข้อเฉพาะ)

อะไรคือเหตุผล?

• ชุดรูปแบบของ GoF จริง ๆ แล้วครอบคลุมกว่าที่ฉันคิดหรือไม่

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

• อื่น ๆ อีก?

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

• "ชุมชนรูปแบบ" , WikiWikiWeb
• "กลุ่มศึกษารูปแบบการออกแบบของนครนิวยอร์ก" , ลอจิกอุตสาหกรรม
• "แคตตาล็อกรูปแบบ" , The Hillside Group

แต่แล้ว...

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

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

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

และคนจำนวนมากเกินไปกลายเป็นคนที่หลงใหลในแนวคิดและพยายามใช้รูปแบบทุกที่ - โดยปกติแล้วในโค้ดผลลัพธ์คุณไม่สามารถหาการออกแบบที่แท้จริงระหว่าง Singletons (ไร้ความหมายอย่างสมบูรณ์) และ Abstract Factories

ฉันรู้สึกว่ารูปแบบทั้ง 23 ควรเป็นเพียงตัวอย่างเล็ก ๆ ของบางสิ่งที่ใหญ่กว่าซึ่งฉันชอบเรียกว่า Pattern Space

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

รูปแบบการออกแบบ (ในความหมายของ GoF) มีวัตถุประสงค์เพียงประการเดียว: เพื่อชดเชยข้อบกพร่องในภาษาการเขียนโปรแกรมที่คุณใช้

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

ฉันคิดว่ามีสามปัจจัยที่เข้ามาเล่นที่นี่

ขาดมวลวิกฤต

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

รูปแบบไม่เคยสร้างมวลวิกฤตที่พวกเขาต้องการเพื่อให้บรรลุถึงแม้ว่า ค่อนข้างตรงกันข้าม AAMOF ในช่วง 20 ปี (หรือมากกว่านั้น) นับตั้งแต่หนังสือ GoF ออกมาฉันค่อนข้างแน่ใจว่าฉันไม่เคยเห็นการสนทนาเป็นโหลมากเท่าที่ทุกคนที่เกี่ยวข้องจะรู้รูปแบบการออกแบบที่เพียงพอสำหรับใช้ในการปรับปรุงการสื่อสาร

หากต้องการทำให้มันดูแปลกตากว่าเดิมเล็กน้อย: รูปแบบการออกแบบล้มเหลวโดยเฉพาะเพราะไม่ได้ผล

รูปแบบมากเกินไป

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

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

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

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

ขาดความสนใจ

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

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

สรุป

รูปแบบการออกแบบล้มเหลวเนื่องจาก:

1. พวกเขาไม่สามารถบรรลุมวลวิกฤต
2. ความแตกต่างระหว่างรูปแบบไม่เพียงพอที่จะรับประกันความชัดเจน
3. พวกเขาส่วนใหญ่จัดการกับส่วนของรหัสเกือบไม่มีใครสนใจจริง ๆ อยู่แล้ว

รูปแบบที่ขาดหายไป abstractions รูปแบบง่าย ๆ ถูกทำให้เป็นนามธรรม, รูปแบบที่ซับซ้อนไม่เป็นที่รู้จักดังนั้นรูปแบบจะไม่เป็นประโยชน์

ฉันคิดว่า Paul Graham พูดดีที่สุด:

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

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

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

สิ่งที่ไม่มีคำตอบอื่น ๆ พูดถึงที่เกี่ยวข้อง:

การเพิ่มขึ้นของภาษาที่พิมพ์แบบไดนามิก

เมื่อหนังสือออกมาก่อนก็มีการพูดคุยกันอย่างจริงจังว่า Java นั้นช้าเกินกว่าที่จะทำงานจริงได้จริงตอนนี้ Java นั้นถูกใช้มากกว่าภาษาที่แสดงออกมากขึ้นเนื่องจากความเร็ว บางที Ruby, Python, JavaScript, et al อาจจะช้าเกินไปสำหรับแอปพลิเคชั่นบางประเภทที่มีความสำคัญ แต่โดยส่วนใหญ่แล้วมันจะเร็วพอสำหรับการใช้งานส่วนใหญ่ อย่างน้อย JavaScript ก็เร็วขึ้นเรื่อย ๆ แม้ว่าจะมีฟีเจอร์ที่บรรจุอยู่ในทุกรีลีส

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

มันไม่เกิดขึ้น มีหลายสิบถ้าไม่ใช่หนังสือหลายร้อยเล่มที่ถูกตีพิมพ์ในสิ่งที่ดูเหมือนจะเป็นความพยายามที่จะลดทั้งวิทยาการคอมพิวเตอร์ในการออกแบบรูปแบบในขณะที่ผู้จัดพิมพ์และผู้แต่งพยายามที่จะข้ามไป (หรือสร้าง) อีก bandwagon ฉันมีชั้นวางของ ไม่เคยปรึกษาตั้งแต่การสแกนครั้งแรกและใช่ฉันเป็นคนดูดเนื่องจากมีการใช้งานจริงน้อยมากหรือไม่มีเลยหรือไม่เป็นที่รู้จักกันดี (ดูตัวอย่างประเภทวัตถุซึ่งไม่มีอะไรมากกว่าแบบฟอร์มปกติที่สามที่แสดง โหลหน้าแทนที่จะเป็นหนึ่งย่อหน้า) และเพราะเห็นได้ชัดว่ารูปแบบที่น้อยลงนั้นดีกว่านั่นคือจุดที่ทำให้ผู้ฝึกปฏิบัติส่วนใหญ่ แน่นอนเมื่อฉันโพสต์การโต้แย้งของ Type Object ฉันได้รับคำสั่งให้แต่งข้อความใหม่เป็นลวดลายการออกแบบเรื่องจริง. ซึ่งยังแสดงให้เห็นข้อบกพร่องของโครงการอื่น: ไม่มีการตรวจสอบหรือยกเว้นหรือกลไกการปฏิเสธ

ตามความเป็นจริงแล้ว GoF ไม่ได้พยายาม 'สำรวจรูปแบบการออกแบบ' อย่างละเอียด แต่พวกเขามีส่วนร่วมในโครงการขนาดใหญ่กว่ามาก: เพื่อแนะนำ 'pattern pattern' ให้กับ CS พร้อมกับอาร์คาน่าที่แปลกประหลาดของ Forces, Forces, Participants และอื่น ๆ ซึ่งล้มเหลวเพราะมันเป็นความเข้าใจผิดขั้นพื้นฐาน

สิ่งที่พวกเขาทำสำเร็จซึ่งมีประโยชน์มีสองสิ่ง:

• เผยแพร่เทคนิคที่มีประโยชน์หลายประการเช่นรูปแบบผู้เข้าชม
• ระบุชื่อมาตรฐานที่ส่วนใหญ่ติดอยู่: Factory, Adaptor, Iterator, ... หากคุณดูที่ CORBA ซึ่งได้รับการออกแบบมาก่อนล่วงหน้าคุณจะเห็นคุณค่าของสิ่งนี้: ชื่อต่างประเทศทุกประเภทเช่น Interceptor , คนรับใช้, นายหน้า, ...

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

มี / ได้รับการหนังสือหลายเล่มชื่อป๋อม ( ภาษารูปแบบของการออกแบบโปรแกรม ) ซึ่งแต่ละบทของเอกสารที่นำเสนอในการประชุมประจำปี

การอ่านหนังสือฉันพบว่ารูปแบบบางอย่างน่าสนใจและใหม่สำหรับฉันมาตรฐานบางอย่าง (เช่น "half object plus protocol")

ไม่เลยคอลเล็กชั่นของ GoF ไม่ครบถ้วนสมบูรณ์และเป็นแรงบันดาลใจ / เป็นแรงบันดาลใจให้ผู้คนรวบรวม / อธิบาย / ค้นพบ / ประดิษฐ์ใหม่

"รูปแบบเพิ่มเติมเพียง 12 รูปแบบที่ระบุไว้ในบทความ Wikipedia" อาจไม่ใช่คอลเลกชันที่สมบูรณ์เช่น: มีรูปแบบอื่น ๆ ที่บันทึกไว้เช่นในหนังสือ PLoP และที่อื่น ๆ ด้วย

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

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

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

หนังสือรูปแบบการออกแบบโมเด็มอีกหลายเล่มคือ“ การปรับปรุงการปรับปรุงการออกแบบของรหัสที่มีอยู่ (Martin Fowler)”และ“ รหัสสะอาด: คู่มือของงานฝีมือซอฟต์แวร์ Agile (Robert C. Martin) ” หนังสือทั้งสองเล่มนี้นำเสนอเนื้อหาที่เปลี่ยนแปลง ถึงรหัสปัจจุบันของคุณแทนที่จะเป็น "การออกแบบกระป๋องที่นำกลับมาใช้ใหม่ได้" แต่มันก็เป็น "ลวดลายการออกแบบ" มาก

นี่คือบทสัมภาษณ์ของ Erich Gamma ที่ซึ่งเขาไตร่ตรองเกี่ยวกับการเลือกรูปแบบและสิ่งที่พวกเขาต้องการเปลี่ยนแปลงในวันนี้

http://www.informit.com/articles/article.aspx?p=1404056

Larry:คุณจะสร้าง "รูปแบบการออกแบบ" ได้อย่างไร

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

เมื่อพูดถึงรูปแบบที่จะวางเราพบว่าเรายังคงรักพวกเขาทั้งหมด (ไม่จริง - ฉันชอบที่จะทิ้ง Singleton การใช้มันมักจะเป็นกลิ่นการออกแบบเสมอ)

ดังนั้นนี่คือการเปลี่ยนแปลงบางอย่าง:

• ล่ามและฟลายเวทควรจะถูกย้ายไปอยู่ในหมวดหมู่แยกต่างหากที่เราเรียกว่า "อื่น ๆ / สารประกอบ" เนื่องจากเป็นสัตว์ที่แตกต่างจากรูปแบบอื่น ๆ วิธีการของโรงงานจะถูกนำไปใช้กับโรงงาน
• หมวดหมู่คือ: Core, Creational, อุปกรณ์ต่อพ่วงและอื่น ๆ ความตั้งใจที่นี่คือการเน้นรูปแบบที่สำคัญและแยกพวกเขาออกจากคนที่ใช้น้อยกว่า
• สมาชิกใหม่คือ: Null Object, Type Object, Dependency Injection และ Extension Object / Interface (ดูที่ "Object Extension" ในรูปแบบภาษาของการออกแบบโปรแกรม 3, Addison- Wesley, 1997)
• นี่คือหมวดหมู่:
  • แกนหลัก: คอมโพสิตกลยุทธ์รัฐคำสั่ง Iterator พร็อกซีวิธีเทมเพลต
  • Creational: โรงงานต้นแบบผู้สร้างพึ่งพาการฉีด
  • อุปกรณ์ต่อพ่วง: โรงงานที่เป็นนามธรรมผู้เข้าชมมัณฑนากรผู้ไกล่เกลี่ยวัตถุประเภทวัตถุว่างเปล่าวัตถุส่วนขยาย
  • อื่น ๆ : Flyweight, Interpreter

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

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

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

มันไม่ได้เกิดขึ้น มากกว่า 20 ปีหลังจากหนังสือ GoF ออกมามีเพียง 12 รูปแบบเพิ่มเติมที่ปรากฏในบทความ Wikipedia ซึ่งส่วนใหญ่เป็นที่นิยมน้อยกว่าต้นฉบับมาก (ฉันไม่ได้รวมรูปแบบการทำงานพร้อมกันที่นี่เพราะครอบคลุมหัวข้อเฉพาะ)

หนังสือ GoF และ Wikipedia แทบจะไม่เป็นแหล่งเดียวของรูปแบบการออกแบบที่เป็นที่รู้จัก หากคุณเพียงแค่ค้นหา "รูปแบบการออกแบบ" ใน Amazon.com คุณจะได้รับหนังสือหลายร้อยเล่ม (ลองค้นหานี้) ฉันเดาว่าพวกเขามีรูปแบบที่เป็นที่รู้จักมากที่สุดในบทความ Wikipediaเท่านั้น

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

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

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

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

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

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