วิธีการยึดมั่นในหลักการเปิดในทางปฏิบัติ

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

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

1. ก่อน: โปรแกรมไปยัง abstractions และ 'ทำนายอนาคต' มากที่สุดเท่าที่จะทำได้ ตัวอย่างเช่นวิธีการdrive(Car car)จะต้องเปลี่ยนหาก Motorcycleมีการเพิ่ม s ในระบบในอนาคตดังนั้นจึงอาจละเมิด OCP แต่วิธีdrive(MotorVehicle vehicle)นี้มีแนวโน้มที่จะไม่เปลี่ยนแปลงในอนาคตดังนั้นจึงเป็นไปตาม OCP

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

2. หลังจาก: เมื่อต้องการการเปลี่ยนแปลงให้ขยายคลาสแทนการแก้ไขเป็นรหัสปัจจุบัน

แบบฝึก # 1 ไม่ยากที่จะเข้าใจ อย่างไรก็ตามมันเป็นข้อปฏิบัติที่ 2 ที่ฉันมีปัญหาในการทำความเข้าใจวิธีการสมัคร

ยกตัวอย่างเช่น (ฉันเอามันจากวิดีโอบน YouTube): ขอบอกว่าเรามีวิธีการในระดับที่ยอมรับได้วัตถุ:CreditCard makePayment(CraditCard card)หนึ่งวันVoucherจะถูกเพิ่มเข้าไปในระบบ วิธีนี้ไม่รองรับพวกมันดังนั้นจึงต้องมีการแก้ไข

เมื่อนำวิธีการนี้ไปใช้ในตอนแรกเราไม่สามารถคาดการณ์อนาคตและโปรแกรมในแง่นามธรรมได้มากขึ้น (เช่นmakePayment(Payment pay)ดังนั้นตอนนี้เราต้องเปลี่ยนรหัสที่มีอยู่

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

หรือหลักการไม่ได้อ้างถึง 'วิธีการแก้ไข / เพิ่มฟังก์ชันการทำงานที่ถูกต้อง' แต่หมายถึง 'วิธีหลีกเลี่ยงการเปลี่ยนแปลงในตอนแรก (เช่นโปรแกรมไปยัง abstractions)?

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

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

ในทางปฏิบัติเมื่อคุณมีสองแอปพลิเคชันเท่านั้นการรีแฟคเตอร์เมื่อคุณเพิ่มแอปที่สามมักไม่ยาก เมื่อคุณปล่อยให้มันผ่านพ้นจุดนั้นไปมันจะลำบากในการรักษา

ฉันคิดว่าคุณมองไกลเกินไปในอนาคต แก้ปัญหาปัจจุบันด้วยวิธีที่ยืดหยุ่นซึ่งยึดติดกับเปิด / ปิด

สมมติว่าคุณต้องใช้drive(Car car)วิธีการ ขึ้นอยู่กับภาษาของคุณคุณมีสองตัวเลือก

• สำหรับภาษาที่รองรับการโอเวอร์โหลด (C ++) จากนั้นใช้ drive(const Car& car)

  ในบางจุดในภายหลังคุณอาจต้องแต่มันจะไม่ยุ่งเกี่ยวกับdrive(const Motorcycle& motorcycle) drive(const Car& car)ไม่มีปัญหา!

• สำหรับภาษาที่ไม่สนับสนุนการบรรทุกเกินพิกัด (วัตถุประสงค์ C) -driveCar:(Car *)carแล้วรวมถึงชื่อชนิดในวิธีการ

  ในบางจุดในภายหลังคุณอาจต้องการ-driveMotorcycle:(Motorcycle *)motorcycleแต่อีกครั้งมันจะไม่รบกวน

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

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

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

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

นั่นหมายความว่าอย่างไร? ฉันควรคลาสย่อยคลาสที่มีอยู่แทนที่เพียงแค่เปลี่ยนเป็นรหัสเดิมหรือไม่

ได้.

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

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

พฤติกรรมใหม่ = คลาสใหม่

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