เหตุใดนักพัฒนาซอฟต์แวร์หลายคนจึงละเมิดหลักการเปิด / ปิด

เหตุใดนักพัฒนาซอฟต์แวร์หลายคนจึงละเมิดหลักการเปิด / ปิดโดยการปรับเปลี่ยนหลายอย่างเช่นการเปลี่ยนชื่อฟังก์ชั่นซึ่งจะทำให้แอปพลิเคชั่นแตกหลังจากอัพเกรด

คำถามนี้ข้ามไปที่หัวของฉันหลังจากเวอร์ชันที่รวดเร็วและต่อเนื่องในไลบรารีReact

ทุกช่วงเวลาสั้น ๆ ฉันสังเกตเห็นการเปลี่ยนแปลงมากมายในไวยากรณ์ชื่อส่วนประกอบ ... ฯลฯ

ตัวอย่างในReact รุ่นที่กำลังมา :

คำเตือนการเลิกใช้ใหม่

การเปลี่ยนแปลงที่ยิ่งใหญ่ที่สุดคือเราได้ดึง React.PropTypes และ React.createClass ลงในแพ็คเกจของตัวเองแล้ว ทั้งสองยังสามารถเข้าถึงได้ผ่านวัตถุหลักปฏิกิริยา แต่การใช้อย่างใดอย่างหนึ่งจะบันทึกคำเตือนการคัดค้านเพียงครั้งเดียวไปยังคอนโซลเมื่ออยู่ในโหมดการพัฒนา นี่จะเป็นการเปิดใช้งานการปรับขนาดโค้ดในอนาคต

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

• การเปลี่ยนแปลงเหล่านี้ถือเป็นการละเมิดหลักการนั้นหรือไม่?
• ในฐานะผู้เริ่มต้นสำหรับบางอย่างเช่นReactฉันจะเรียนรู้ได้อย่างไรด้วยการเปลี่ยนแปลงอย่างรวดเร็วในไลบรารี (มันน่าผิดหวังมาก)

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

ดังที่Jörg W Mittag พูดถึงในความคิดเห็นของเขาแล้วหลักการไม่ได้กล่าวว่า "คุณไม่สามารถปรับเปลี่ยนพฤติกรรมขององค์ประกอบได้" - กล่าวว่าเราควรพยายามออกแบบส่วนประกอบในวิธีที่พวกเขาเปิดเพื่อนำผึ้งกลับมาใช้ใหม่ (หรือขยาย) ในหลายวิธีโดยไม่จำเป็นต้องดัดแปลง สิ่งนี้สามารถทำได้โดยการระบุ "จุดขยาย" หรือ @AntP ที่ถูกต้อง "โดยการแยกโครงสร้างคลาส / ฟังก์ชั่นไปยังจุดที่ทุกจุดขยายธรรมชาติมีอยู่โดยค่าเริ่มต้น" IMHO ที่ติดตาม OCP นั้นไม่มีอะไรเหมือนกันกับ"การรักษาเวอร์ชั่นเก่าไว้โดยไม่เปลี่ยนแปลงเพื่อความเข้ากันได้ย้อนหลัง" ! หรืออ้างถึงความคิดเห็นของ @ DerekElkin ด้านล่าง:

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

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

หลักการเปิด / ปิดมีประโยชน์ แต่ก็มีข้อเสียร้ายแรง

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

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

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

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

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

เห็นได้ชัดว่าผู้พัฒนา React รู้สึกว่ามันไม่คุ้มกับค่าใช้จ่ายในความซับซ้อนและการขยายโค้ดเพื่อปฏิบัติตามหลักการเปิด / ปิดอย่างเคร่งครัด

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

(การตีความของฉันของหลักการขึ้นอยู่กับหลักการOpen-Closedโดย Robert C. Martin)

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

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

ตัวอย่างที่มีชื่อเสียงของสิ่งนี้พบได้ในตัวจัดการหน่วยความจำ Windows 95 ในฐานะส่วนหนึ่งของการตลาดสำหรับ Windows 95 มีการระบุว่าแอปพลิเคชัน Windows 3.1 ทั้งหมดจะทำงานใน Windows 95 Microsoft ได้รับสิทธิ์การใช้งานจริงสำหรับโปรแกรมหลายพันโปรแกรมเพื่อทดสอบใน Windows 95 กรณีปัญหาหนึ่งคือ Sim City Sim City มีข้อผิดพลาดซึ่งทำให้เขียนหน่วยความจำไม่ได้ปันส่วน ใน Windows 3.1 โดยไม่มีตัวจัดการหน่วยความจำ "เหมาะสม" นี่เป็นความผิดพลาดเล็กน้อย อย่างไรก็ตามใน Windows 95 ตัวจัดการหน่วยความจำจะตรวจจับสิ่งนี้และทำให้เกิดความผิดพลาดในการแบ่งส่วน การแก้ไขปัญหา? ใน Windows 95 หากชื่อแอปพลิเคชันของคุณเป็นsimcity.exeจริง OS จะคลายข้อ จำกัด ของตัวจัดการหน่วยความจำเพื่อป้องกันความผิดพลาดในการแบ่งกลุ่ม!

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

ซอฟต์แวร์ส่วนใหญ่ในปัจจุบันโดยเฉพาะโอเพนซอร์ซเป็นไปตามเวอร์ชันผ่อนคลายทั่วไปของหลักการเปิด / ปิด เป็นเรื่องธรรมดามากที่จะเห็นเปิด / ปิดตามมาอย่างไม่น่าเชื่อสำหรับรุ่นเล็ก ๆ น้อย ๆ แต่ถูกปล่อยปละละเลยสำหรับรุ่นใหญ่ ตัวอย่างเช่น Python 2.7 มี "ตัวเลือกที่ไม่ดี" มากมายจาก Python 2.0 และ 2.1 วัน แต่ Python 3.0 กวาดพวกเขาทั้งหมดออกไป (นอกจากนี้การเปลี่ยนจาก Windows 95 codebase กับ codebase Windows NT เมื่อพวกเขาเปิดตัว Windows 2000 ยากจนทุกประเภทของสิ่ง แต่มันไม่ได้หมายความว่าเราไม่เคยมีการจัดการกับผู้จัดการหน่วยความจำการตรวจสอบชื่อโปรแกรมที่จะตัดสินใจพฤติกรรม!)

คำตอบของ Doc Brown นั้นใกล้เคียงกับความถูกต้องส่วนคำตอบอื่น ๆ แสดงให้เห็นถึงความเข้าใจผิดของหลักการ Open Open

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

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

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

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

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

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

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