ตามที่ฉันได้อธิบายหลักการเปิด / ปิดระบุว่าเมื่อเขียนรหัสไม่ควรแก้ไข (นอกเหนือจากการแก้ไขข้อผิดพลาด) แต่หากกฎธุรกิจของฉันเปลี่ยนฉันไม่ควรแก้ไขรหัสที่ใช้การเปลี่ยนแปลงเหล่านั้นหรือ ฉันสงสัยว่าฉันไม่เข้าใจบางสิ่งเกี่ยวกับหลักการเพราะมันไม่สมเหตุสมผลสำหรับฉัน
คำตอบ:
นี่อาจเป็นหลักการที่ยากที่สุดในการอธิบาย ให้ฉันพยายาม. ลองนึกภาพคุณเขียนคลาสใบแจ้งหนี้ที่ทำงานได้อย่างสมบูรณ์และไม่มีข้อบกพร่อง มันทำให้ PDF ของใบแจ้งหนี้
จากนั้นมีคนบอกว่าพวกเขาต้องการใบแจ้งหนี้ HTML พร้อมลิงก์ในนั้น คุณไม่ได้เปลี่ยนรหัสใด ๆ ในใบแจ้งหนี้เพื่อตอบสนองคำขอนี้ คุณสร้างคลาส HTMLInvoice แทนซึ่งเป็นสิ่งที่พวกเขาต้องการในขณะนี้ คุณใช้ประโยชน์จากการสืบทอดเพื่อที่คุณจะได้ไม่ต้องเขียนโค้ดซ้ำจำนวนมากใน HTMLInvoice
รหัสเก่าที่ใช้ใบแจ้งหนี้เก่าไม่ได้ขาดหรือได้รับผลกระทบใด ๆ รหัสใหม่สามารถใช้ HTMLInvoice (ถ้าคุณใช้Liskov Substitutability , L of solid คุณสามารถมอบ HTMLInvoice instance ให้กับโค้ดที่มีอยู่ซึ่งคาดว่าจะอินสแตนซ์ Invoice) ทุกคนใช้ชีวิตอย่างมีความสุขตลอดไป
ใบแจ้งหนี้ถูกปิดเพื่อแก้ไขเปิดเพื่อขยาย และคุณต้องเขียนใบแจ้งหนี้อย่างถูกต้องล่วงหน้าเพื่อให้สิ่งนี้ทำงาน btw
คุณได้อ่านบทความThe Open หลักการที่ปิดโดยเพื่อน ๆ ของลุงบ๊อบที่ ObjectMentor หรือไม่? ฉันคิดว่านี่เป็นหนึ่งในคำอธิบายที่ดีกว่า
มีฮิวริสติกจำนวนมากที่เกี่ยวข้องกับการออกแบบเชิงวัตถุ ตัวอย่างเช่น "ตัวแปรสมาชิกทั้งหมดควรเป็นส่วนตัว" หรือ "ควรหลีกเลี่ยงตัวแปรส่วนกลาง" หรือ "การใช้การระบุประเภทเวลาทำงาน (RTTI) เป็นอันตราย" แหล่งที่มาของการวิเคราะห์พฤติกรรมเหล่านี้คืออะไร? อะไรทำให้พวกเขาเป็นจริง พวกเขาเป็นจริงเสมอ คอลัมน์นี้จะตรวจสอบหลักการออกแบบที่รองรับฮิวริสติกเหล่านี้ - หลักการแบบเปิด
ดังที่ Ivar Jacobson กล่าวว่า“ ทุกระบบเปลี่ยนแปลงในช่วงชีวิตของพวกเขา สิ่งนี้จะต้องเกิดขึ้นในใจเมื่อการพัฒนาระบบคาดว่าจะยาวนานกว่ารุ่นแรก” เราจะสร้างการออกแบบที่มีความเสถียรเมื่อเผชิญกับการเปลี่ยนแปลงได้อย่างไรและจะยาวนานกว่ารุ่นแรกอย่างไร เบอร์ทรานด์เมเยอร์ให้คำแนะนำกับเราเมื่อปี 1988 เมื่อเขาประกาศใช้หลักการแบบเปิดที่มีชื่อเสียงในขณะนี้ เพื่อถอดความเขา:
ซอฟแวร์ ENTITIES (คลาส, โมดูล, ฟังก์ชั่น, ฯลฯ ) ควรเปิดสำหรับการขยาย, แต่ปิดสำหรับการดัดแปลง
เมื่อการเปลี่ยนแปลงหนึ่งครั้งในโปรแกรมส่งผลให้เกิดการเปลี่ยนแปลงของโมดูลที่ต้องพึ่งพาโปรแกรมนั้นจะแสดงคุณลักษณะที่ไม่พึงประสงค์ซึ่งเราได้เชื่อมโยงกับการออกแบบ "ไม่ดี" โปรแกรมกลายเปราะบางเข้มงวดไม่สามารถคาดเดาได้และไม่สามารถใช้งานได้ หลักการแบบเปิดปิดเป็นการโจมตีในลักษณะที่ตรงไปตรงมามาก มันบอกว่าคุณควรออกแบบโมดูลที่ไม่เคยเปลี่ยน เมื่อความต้องการเปลี่ยนแปลงคุณขยายการทำงานของโมดูลดังกล่าวโดยเพิ่มรหัสใหม่ไม่ใช่โดยการเปลี่ยนรหัสเก่าที่ใช้งานได้
ลักษณะ
โมดูลที่สอดคล้องกับหลักการเปิดมีสองคุณสมบัติหลัก
- พวกเขาคือ“ เปิดเพื่อการขยาย”
ซึ่งหมายความว่าพฤติกรรมของโมดูลสามารถขยายได้ เราสามารถทำให้โมดูลทำงานในรูปแบบใหม่และแตกต่างกันไปตามข้อกำหนดของการเปลี่ยนแปลงแอปพลิเคชันหรือเพื่อตอบสนองความต้องการของแอปพลิเคชันใหม่- พวกเขาคือ“ ปิดเพื่อแก้ไข”
ซอร์สโค้ดของโมดูลดังกล่าวไม่ถูกทำลาย ไม่มีใครได้รับอนุญาตให้ทำการเปลี่ยนแปลงซอร์สโค้ดมันดูเหมือนว่าทั้งสองคุณลักษณะจะขัดแย้งกัน วิธีปกติในการขยายลักษณะการทำงานของโมดูลคือทำการเปลี่ยนแปลงกับโมดูลนั้น โดยปกติโมดูลที่ไม่สามารถเปลี่ยนแปลงได้จะคิดว่ามีพฤติกรรมที่คงที่ แอตทริบิวต์ของทั้งสองฝั่งตรงข้ามสามารถแก้ไขได้อย่างไร?
สิ่งที่เป็นนามธรรมคือกุญแจสำคัญ ...
คำตอบโดยเคทเกรกอรี่เป็นสิ่งที่ดีมาก แต่พิจารณาสถานการณ์ที่แตกต่างกันที่ความต้องการใหม่ที่สามารถรับความพึงพอใจจากการเปลี่ยนแปลงที่ค่อนข้างเล็กในที่มีอยู่Invoiceในชั้นเรียน ตัวอย่างเช่นสมมติว่าต้องเพิ่มฟิลด์ใหม่ใน PDF ใบแจ้งหนี้ ตาม OCP เรายังควรสร้างคลาสย่อยใหม่แม้ว่าจะสามารถเพิ่มฟิลด์ใหม่ในการใช้งานที่มีอยู่โดยการเปลี่ยนโค้ดไม่กี่บรรทัด
ในความเข้าใจของฉัน OCP สะท้อนให้เห็นถึงความเป็นจริงของยุค 80 และต้นยุค 90 ที่โครงการมักไม่ใช้การควบคุมเวอร์ชันมีการทดสอบการถดถอยแบบอัตโนมัติน้อยมากหรือประโยชน์ของเครื่องมือการรีแฟคเตอร์ที่ซับซ้อน OCP เป็นความพยายามที่จะหลีกเลี่ยงความเสี่ยงของรหัสที่ได้รับการทดสอบและนำไปผลิต วันนี้เรามีวิธีที่ดีกว่าในการจัดการความเสี่ยงในการทำลายซอฟต์แวร์ที่ใช้งานได้ (เช่นระบบควบคุมเวอร์ชัน, TDD และการทดสอบอัตโนมัติและเครื่องมือการเปลี่ยนโครงสร้างใหม่)
โดยส่วนตัวแล้วฉันคิดว่าหลักการนี้ควรใช้เกลือนิดหน่อย รหัสเป็นเรื่องธรรมดาการเปลี่ยนแปลงธุรกิจและการเปลี่ยนรหัสตามความต้องการของธุรกิจเมื่อเวลาผ่านไป
ฉันพบว่ามันยากมากที่จะเข้าใจความจริงที่ว่านามธรรมเป็นกุญแจสำคัญ เกิดอะไรขึ้นถ้าสิ่งที่เป็นนามธรรมผิดเดิม? ถ้าฟังก์ชั่นธุรกิจมีการเปลี่ยนแปลงอย่างมีนัยสำคัญ?
หลักการนี้ทำให้แน่ใจได้ว่าความตั้งใจดั้งเดิมและพฤติกรรมของการออกแบบจะต้องไม่เปลี่ยนแปลง นั่นอาจใช้ได้กับผู้ที่มี API สาธารณะและลูกค้าของพวกเขามีปัญหาในการติดตามข่าวใหม่และกรณีอื่น ๆ อย่างไรก็ตามหาก บริษัท เป็นเจ้าของรหัสทั้งหมดฉันก็จะท้าทายหลักการนี้
การมีการทดสอบที่ครอบคลุมของรหัสของคุณควรทำให้การสร้างรหัสของคุณง่ายขึ้น หมายความว่าไม่เป็นไรที่จะทำสิ่งผิดปกติการทดสอบของคุณจะช่วยนำทางคุณไปสู่การออกแบบที่ดีขึ้น
บอกว่าถ้าไม่มีการทดสอบใด ๆ แล้วหลักการนี้เป็นเสียง