खुला/बंद सिद्धांत (Open/Closed Principle, OCP) कहता है कि सॉफ्टवेयर इकाइयों को विस्तार के लिए खुला लेकिन संशोधन के लिए बंद होना चाहिए: आपको नया व्यवहार नए कोड को जोड़कर जोड़ना चाहिए, मौजूदा, परीक्षित कोड को संपादित करके नहीं।
():
shape.kind == : * shape.r **
shape.kind == : shape.s **
shape.kind == : shape.w * shape.h
प्रत्येक नया प्रकार बढ़ती if/elif श्रृंखला में परिवर्तन को मजबूर करता है — नाजुक और बग के लिए एक चुंबक।
from abc import ABC, abstractmethod
class Shape(ABC):
@abstractmethod
def area(self): ...
class Circle(Shape):
def __init__(self, r): self.r = r
def area(self): return 3.14159 * self.r ** 2
class Triangle(Shape): # NEW behavior = NEW class
def __init__(self, b, h): self.b, self.h = b, h
def area(self): return 0.5 * self.b * self.h
def total_area(shapes): # never changes again
return sum(s.area() for s in shapes)
Triangle जोड़ने के लिए total_area में शून्य संपादन की आवश्यकता है — संशोधन के बिना विस्तार।
→ polymorphism / inheritance → strategy pattern (inject behavior)
→ plugins / interfaces → higher-order functions / callbacks
OCP को अनुमानित रूप से किया गया अत्यधिक-इंजीनियरिंग बन जाता है — भिन्नता के लिए बनाए गए अमूर्त जो कभी नहीं आते। इसे वहां लागू करें जहां परिवर्तन संभव है ("तीन का नियम": भिन्नता वास्तव में दिखाई देने के बाद सार)।
संसाधित कोड को एक सुविधा जोड़ने के लिए संपादित करना उन सभी चीजों में प्रतिगमन का जोखिम उठाता है जो वह कोड पहले से समर्थन करता है; OCP नए व्यवहार को नई, अलग-थलग इकाइयों तक सीमित करता है।
यह विस्तार योग्य फ्रेमवर्क और प्लगइन सिस्टम के पीछे का सिद्धांत है — और यह LSP पर निर्भर करता है, क्योंकि प्रतिस्थापनीय उप-प्रकार वह हैं जो "बंद" कोर को अछूत रहने के लिए सुरक्षित बनाते हैं।