Open/Closed Principle को विस्तारमा व्याख्या गर्नुहोस्।

Question

Accepted Answer

**Open/Closed Principle (OCP)** भन्छ कि सफ्टवेयर इकाइहरू **विस्तारको लागि खुला तर परिमार्जनको लागि बन्द** हुनुपर्छ: तपाइँले अवस्थित, परीक्षण गरिएको कोड सम्पादन गरेर होइन, नयाँ कोड थपेर नयाँ व्यवहार थप्नुपर्छ।

## OCP ले लक्ष्य गरेको smell

```python
# CLOSED to extension: every new shape edits this method (risky, retests everything)
def area(shape):
    if shape.kind == "circle":   return 3.14159 * shape.r ** 2
    elif shape.kind == "square": return shape.s ** 2
    elif shape.kind == "rect":   return shape.w * shape.h
    # add a triangle → modify this function again...
```

प्रत्येक नयाँ प्रकारले बढ्दो `if/elif` chain मा परिवर्तन बाध्य गर्छ — नाजुक र bugs को चुम्बक।

## OCP polymorphism को माध्यमबाट

```python
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` मा **शून्य सम्पादन** चाहिन्छ — परिमार्जन बिना विस्तार।

## OCP लाई सक्षम गर्ने तन्त्र

```text
→ polymorphism / inheritance     → strategy pattern (inject behavior)
→ plugins / interfaces           → higher-order functions / callbacks
```

## खतरा

OCP को विशेषणात्मक रूपमा गरिएको कार्य over-engineering बन्न सक्छ — विविधताको लागि बनेका अमूर्तताहरू जो कहिले आउँदैन। यो जहाँ परिवर्तन *सम्भावित* छ त्यहाँ लागु गर्नुहोस् ("rule of three": विविधता वास्तवमा आएपछि अमूर्त गर्नुहोस्)।

## किन यो महत्त्वपूर्ण छ

नयाँ सुविधा थप्न battle-tested कोड सम्पादन गर्नुले त्यो कोडले पहिले नै समर्थन गरेको सबै कुरामा regression को जोखिम राख्छ; OCP ले नयाँ व्यवहारलाई नयाँ, अलग इकाइहरूमा सीमाबद्ध गर्छ।

यो विस्तार योग्य frameworks र plugin systems को पछाडिको सिद्धान्त हो — र यो LSP मा निर्भर गर्छ, किनभने substitutable subtypes हरू नै "बन्द" core लाई अछुत राख्न सुरक्षित गर्छन्।