ฉันควรใช้ความพยายามมากแค่ไหนในการสร้างการออกแบบที่ควบคู่กันอย่างหลวม ๆ

ปัจจุบันฉันเรียนรู้เกี่ยวกับรูปแบบการออกแบบ

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

ด้วยสิ่งนี้ในใจ:

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

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

ฉันเข้าใจถึงความสำคัญและประโยชน์ของข้อต่อหลวม

แต่คำถามของฉันคือต้องใช้ความพยายามมากแค่ไหนในการสร้างการออกแบบที่มีความยืดหยุ่นและหลวม

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

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

คำตอบที่เยือกเย็น: ยิ่งคุณทำมากเท่าไหร่ก็ยิ่งพยายามน้อยเท่านั้น

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

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

สิ่งนี้เกิดขึ้น มาก. มันทำให้โครงการทำงานช้าหรือทำให้ทุกคนกลัวเกินกว่าที่จะทำในสิ่งที่ต้องทำในภายหลัง ในกรณีที่ดีที่สุดคุณจะได้ Big Ball of Mud สิ่งต่าง ๆ เช่นการแต่งงานกันอย่างหลวม ๆ และหลักการความรับผิดชอบเดียวช่วยลดปัญหาเหล่านี้ได้อย่างมาก นั่นเป็นเหตุผลว่าทำไมหลักการของ SOLID จึงได้รับการขนานนาม - พวกเขาช่วยได้จริงๆ

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

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

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

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

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

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

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

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

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

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

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

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

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

ควรใช้รูปแบบเฉพาะที่สามารถเป็นทางออกที่ดีที่สุดหรือช่วยในการสร้างทางออกที่ดี (คุณเห็นด้วย?)

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

เราควรลงทุนในการสร้างการออกแบบที่ยืดหยุ่น

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

ท่ามกลางกฎ (ไม่ใช่รายการที่ครบถ้วนสมบูรณ์):

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

กฎเหล่านี้มีการปฏิบัติแตกต่างกันไปตามภาษาวิธีการพัฒนาตามด้วยทีมของคุณ (เช่น TDD) ข้อ จำกัด ด้านงบประมาณและอื่น ๆ

ตัวอย่างเช่นใน Java เป็นแนวปฏิบัติที่ดีในการกำหนดอินเทอร์เฟซของคุณเป็นinterfaceและเขียนรหัสไคลเอนต์บนนั้น (จากนั้นอินสแตนซ์อินเทอร์เฟซที่มีคลาสการใช้งาน)

ใน C ++ คุณไม่มีอินเทอร์เฟซดังนั้นคุณสามารถเขียนอินเทอร์เฟซเป็นคลาสพื้นฐานแบบนามธรรมเท่านั้น เนื่องจากใน C ++ คุณใช้การสืบทอดเมื่อคุณมีข้อกำหนดที่เข้มงวดเท่านั้น (และหลีกเลี่ยงโอเวอร์เฮดของฟังก์ชันเสมือนที่ไม่จำเป็น) คุณอาจไม่ได้กำหนดอินเตอร์เฟสแยกต่างหาก

ผู้ที่คัดค้านรูปแบบการออกแบบบอกว่าค่าใช้จ่ายในการใช้รูปแบบเหล่านี้มักจะมากกว่าประโยชน์

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

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

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

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

ประโยชน์ของการแต่งงานกันคือ:

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

... และอีกสองสามคนที่ไม่ได้มาในความคิดของฉันในขณะนี้