รูปแบบการออกแบบมีความสำคัญอย่างยิ่งในปัจจุบันหรือไม่?

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

ฉันคิดว่ามี 2 เหตุผลหลักสำหรับสิ่งนี้:

1. รูปแบบการออกแบบบังคับให้เราคิดในแง่ของพวกเขา กล่าวอีกนัยหนึ่งแทบจะเป็นไปไม่ได้ที่จะคิดค้นสิ่งใหม่ ๆ (อาจจะดีกว่า)

2. รูปแบบการออกแบบไม่คงอยู่ตลอดไป ภาษาและเทคโนโลยีเปลี่ยนแปลงอย่างรวดเร็ว ดังนั้นรูปแบบการออกแบบในที่สุดจะไม่เกี่ยวข้อง

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

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

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

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

และที่สำคัญที่สุดคือถ้าฉันตั้งชื่อคลาส FooBuilder คุณรู้ว่าฉันใช้รูปแบบตัวสร้างเพื่อสร้าง Foo ของฉัน

แม้ว่าคุณจะไม่รู้ว่าฉันกำลังพูดถึงอะไรเมื่อฉันพูดว่า "รูปแบบการสังเกตการณ์นั้นเหมาะสำหรับสิ่งนั้น" คุณจะสามารถออกไปและ google ได้อย่างง่ายดาย

ในแง่นั้นพลังของรูปแบบการออกแบบจะไม่จางหายไป

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

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

รูปแบบการให้บริการวัตถุประสงค์หลักที่สอง:

• การแก้ปัญหาความตึงเครียดที่คาดการณ์ไว้ : รูปแบบถูกออกแบบมาเพื่อแก้ไขความตึงเครียดบางอย่างในลักษณะที่เป็นที่รู้จักกันในการทำงาน Kent Beck ผู้แต่งSmalltalk Best Practice Patternsอธิบายรูปแบบเป็นวิธีการตัดสินใจซ้ำ ๆ ที่ผู้เชี่ยวชาญจะทำในสถานการณ์ที่คล้ายคลึงกัน ตราบใดที่ความตึงเครียดยังคงเหมือนเดิม (และพวกเขามักทำ) รูปแบบที่แก้ปัญหานั้นจะยังคงมีประโยชน์

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

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

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

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

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

ลวดลายการออกแบบมีสองชนิด:

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

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

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

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

ฉันเชื่อว่าแก๊งค์สี่คนนั้นจำแนกรูปแบบการออกแบบเป็น

วิธีแก้ปัญหาทั่วไปสำหรับปัญหาที่เกิดขึ้นทั่วไป *

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

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

นอกจากนี้เฟรมเวิร์ก. NET ยังมีการสร้างในกลไกเหตุการณ์สำหรับการเผยแพร่เหตุการณ์ไปยังผู้ฟังหลายคนทำให้รูปแบบการสังเกตการณ์มีความเกี่ยวข้องน้อยลงในบริบทนี้

การเปลี่ยนจากแอปพลิเคชันเดสก์ท็อปเป็นเว็บแอปพลิเคชัน ** ยังเปลี่ยนประเภทของปัญหาการเขียนโปรแกรมที่เราต้องแก้ไข รูปแบบหลายอย่างในหนังสือ "Design Patterns" นั้นเกี่ยวข้องกับแอปพลิเคชันบนเดสก์ท็อป แต่ไม่มากสำหรับเว็บแอปพลิเคชัน แน่นอนว่าด้วยแอปหน้าเดียวรูปแบบเหล่านี้อาจเกี่ยวข้องกันอีกครั้งในฝั่งไคลเอ็นต์

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

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

* เครื่องหมายคำพูดอาจไม่ถูกต้อง 100% เนื่องจากนำมาจากหน่วยความจำ

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

*** หลังจากเรียนรู้การเขียนโปรแกรมฟังก์ชั่นและโครงสร้างข้อมูลการทำงานแล้วนั่นอาจเป็นวิธีที่ฉันจะแก้ปัญหาในวันนี้

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