ในโลกทางกายภาพ ประตูที่ปิดคือประตูที่ปิด ในโลกของซอฟต์แวร์ กิจการที่ปิดไปแล้วอาจยังคงเปิดให้ขยายเวลาได้ และควรเป็นไปตามหลักการเปิดปิด (OCP)

มี 2 ​​วิธีที่นิยมนำหลักการนี้ไปใช้ เราจะหารือเกี่ยวกับพวกเขาทั้งสอง

และตัวเลือกที่สาม

#1 — มรดก

นี่เป็นแอปพลิเคชั่นดั้งเดิมของ OCP Bertrand Meyerผู้แนะนำคำนี้ในหนังสือObject-Oriented Software Construction ในปี 1988 ตั้งใจไว้ว่า:

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

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

แต่เปิดCarให้ขยายเวลา. ในความเป็นจริง การขยายเป็นเรื่องง่าย ประเภทย่อย, สามารถขยายจากคลาสพา เรนต์ , จัดหาค่าจริงให้กับ คุณสมบัติ และและเพิ่มคุณสมบัติใหม่และเมธอด ใหม่CarElectricCarCarmodelseatsbatteryLevelrecharge()

#2 — ความหลากหลาย

ทศวรรษที่ 1990 เห็น OCP ตีความใหม่เพื่อส่งเสริมความหลากหลายทางนามธรรมและการนำไปใช้ อ้างอิงจากบทความ “ the Open-Closed Principle ” ของ Robert C. Martin :

สิ่งที่เป็นนามธรรมเป็นกุญแจสำคัญ

สิ่งที่เป็น นามธรรมตามที่ลุงบ๊อบปิดเพื่อแก้ไข แต่เปิดให้ขยายผ่านการใช้งานที่ไม่มีขอบเขต

Carพิจารณาสิ่งที่เป็น นามธรรมโดย ได้รับการแก้ไข แล้วจึงปิด UrbanTripPlannerสำหรับ ข้อกังวลให้Car2 คุณสมบัติ ( modelและseats) และ 2 วิธี ( getSpeed()และgetPosition())

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

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

OCP ผ่าน Abstraction นั้นกว้างกว่าและแข็งแกร่งกว่า

มาขยายมุมมองของเรานอกเหนือจากCarการรวมUrbanTripPlannerและการนำไปใช้งาน หากพวกเขารู้อะไรเกี่ยวกับEletricCarพฤติกรรมที่ประกาศในเมธอดsearchDirection(Car, Position, Position)จะละเมิดหลักการ OCP เนื่องจากต้องแก้ไข จึงไม่ถูกปิดอีกต่อไป เพื่อรองรับประเภทใหม่ของCar. เพื่อหลีกเลี่ยงการละเมิดนี้คือการเพิกเฉยต่อข้อมูลประจำตัวของCarประเภทย่อยทั้งหมด รวมถึงคุณสมบัติและวิธีการเพิ่มเติม ซึ่งลดผลกระทบของการสืบทอดอย่างมีประสิทธิภาพให้เป็นเพียงการนำCarสิ่งที่เป็นนามธรรมไปใช้

นอกจากนี้ ด้วยสิ่งที่เป็นนามธรรม เราเพลิดเพลินกับการสนับสนุนที่มีอยู่มากมายในภาษาโปรแกรมเชิงวัตถุและ IDE สมัยใหม่ ลืมที่จะใช้วิธีการ? มันเป็นข้อผิดพลาดในการรวบรวม ต้องการรับรายชื่อCarในลักษณะที่ปลอดภัยหรือไม่? ทั่วไปList<? extend Car>เพื่อช่วยเหลือ ในตัวอย่างของเรา เนื่องจากUrbanTripPlannerเพียงดูแลCarตราบใดที่ToyotaViosใช้TeslaModel3โปรแกรมCarของเราก็ใช้ได้

#3 — สร้างขึ้นเพื่อการต่อยอด

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

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

ปลั๊กอิน, ส่วนเสริม, ส่วนเสริม

นี่เป็นเพียงชื่อที่แตกต่างกันสำหรับแนวคิดเดียวกัน ตามที่Britannica :

ปลั๊กอิน เรียกอีกอย่างว่าโปรแกรมเสริมหรือส่วนขยาย ซอฟต์แวร์คอมพิวเตอร์ที่เพิ่มฟังก์ชันใหม่ให้กับโปรแกรมโฮสต์โดยไม่แก้ไขโปรแกรมโฮสต์เอง

ดังนั้นปลั๊กอินจึงเป็นตัวอย่างที่ชัดเจนของการเปิดกว้างในโปรแกรมโฮสต์ที่สร้างขึ้นเพื่อส่วนขยาย

มีซอฟต์แวร์หลายประเภทที่ขึ้นอยู่กับส่วนขยายอย่างมาก สำหรับนักพัฒนาของเรา สิ่งนี้ควรเป็นที่คุ้นเคยอย่างใกล้ชิด เนื่องจากเราใช้ปลั๊กอินเพิ่มประสิทธิภาพและภาษาในชีวิตประจำวันใน IDE ที่เราชื่นชอบ เช่น VSCode, Eclipse และ IntelliJ ส่วนขยายเบราว์เซอร์บางตัวมีค่าสำหรับผู้ใช้อินเทอร์เน็ต มีชุดอิโมจิและตัวกรองมากมายเพื่อปรับปรุงประสบการณ์ของผู้ใช้มือถือ...

API, เหตุการณ์

ที่เกี่ยวข้อง แต่สมควรได้รับหมวดหมู่ย่อยของตัวเอง ภายใต้ build-for-extension คือ API และ Events

ส่วนขยายที่รู้จักกันดีที่สุดในหมวดหมู่ย่อยนี้คือโค้ด HTML, CSS และจาวาสคริปต์ พวกเขาทั้งหมดขยายการทำงานของเบราว์เซอร์โดยไม่ต้องแก้ไขภายในของโฮสต์ สิ่งเหล่านี้เกิดขึ้นได้จากความพร้อมใช้งานของ API และเหตุการณ์ที่กำหนดโดยอินเทอร์เฟซที่ตั้งโปรแกรมได้ของเบราว์เซอร์ ความพยายามในการสร้างมาตรฐานมีอยู่จริงและได้ขับเคลื่อนการพัฒนาภูมิทัศน์ของ Web 2.0 และ Web 3.0 ในปัจจุบันเป็นส่วนใหญ่

บทสรุป

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

เราได้เยี่ยมชมวิธีดั้งเดิมสองวิธีในการใช้หลักการนี้: การสืบทอดและนามธรรม อาจเป็นไปได้ว่า Abstraction เป็นที่ต้องการโดยมีผลกระทบที่กว้างกว่าและเอฟเฟกต์ที่แข็งแกร่งกว่า

เรายังตรวจสอบทางเลือกที่สามสำหรับการใช้หลักการ มี 2 ​​หมวดหมู่ย่อยที่โดดเด่น ได้แก่ Plugins และ APIs & Events ภายใต้แนวทางนี้

หากคุณชอบบทความนี้ โปรดติดตามฉันสำหรับเนื้อหาคุณภาพเพิ่มเติม

บทความอื่นๆ ในชุดนี้:

• กลายเป็นนักพัฒนา SOLID
• SOLID in Action — หลักการความรับผิดชอบเดียว
• SOLID in Action — หลักการเปิด-ปิด : บทความนี้
• SOLID in Action — หลักการเปลี่ยนตัวของ Liskov: อยู่ระหว่างการพัฒนา
• SOLID in Action — หลักการแยกอินเทอร์เฟซ: วางแผนไว้
• SOLID in Action — หลักการพึ่งพาการผกผัน: วางแผนไว้