รูปแบบการออกแบบโดยทั่วไปเป็นแรงที่ดีหรือไม่ดีหรือไม่? [ปิด]

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

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

ดังนั้นเมื่อพิจารณาถึงประโยชน์และปัญหารูปแบบการออกแบบโดยทั่วไปดีหรือไม่ดีและเพราะอะไร

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

อเล็กซ์: เฮ้สร้างไฟล์ปรับแต่งยังไง?

บ๊อบ: config.hพวกเขากำลังสร้างโดยโรงงานซึ่งอาศัยอยู่ใน

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

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

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

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

รูปแบบการออกแบบที่ยอดเยี่ยมหากใช้อย่างถูกต้อง

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

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

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

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

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

TL; DR: ใช้ patters ออกแบบ เพียงแค่ไม่ละเมิดพวกเขา

นอกจากนี้ยัง Seet นี้ด้ายในดังนั้น จากอีกรูปแบบการออกแบบของ POV คือรหัสสำเร็จรูปเพื่อชดเชยข้อบกพร่องของวิธีการที่ใช้ ฉันไม่ได้เป็นแฟนของการฉลองการแก้ปัญหาเหล่านั้นมากเกินไป

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

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

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

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

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

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

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

ทั้งสองค่ายนั้นถูกต้อง - พวกมันเป็นพลังที่ดีเมื่อใช้อย่างถูกต้องและเป็นพลังที่ไม่ดีถ้าพวกมันถูกสาดทั่วสถานที่

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

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

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

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