Open/Closed Principle ਨੂੰ ਡੂੰਘਾਈ ਨਾਲ ਸਮਝਾਓ।

Question

Accepted Answer

**Open/Closed Principle (OCP)** ਕਹਿੰਦਾ ਹੈ ਕਿ software entities ਨੂੰ **extension ਲਈ ਖੁੱਲੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਪਰ modification ਲਈ ਬੰਦ**: ਤੁਸੀਂ ਨਵੇਂ ਕੋਡ ਨੂੰ ਜੋੜ ਕੇ ਨਵਾਂ behavior ਜੋੜ ਸਕਦੇ ਹੋ, ਪਰ ਮੌਜੂਦ, tested ਕੋਡ ਨੂੰ edit ਕਰ ਕੇ ਨਹੀਂ।

## ਉਹ smell ਜਿਸ ਨੂੰ OCP target ਕਰਦਾ ਹੈ

```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...
```

ਹਰੇਕ ਨਵਾਂ type `if/elif` chain ਨੂੰ ਲਗਾਤਾਰ ਬਦਲਣ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ — fragile ਅਤੇ bugs ਦਾ ਚੁੰਬਕ।

## OCP via 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` ਨੂੰ ਜੋੜਨ ਲਈ **zero edits** ਜ਼ਰੂਰੀ ਹਨ `total_area` ਵਿੱਚ — extension ਬਿਨਾ modification।

## Mechanisms ਜੋ OCP ਨੂੰ enable ਕਰਦੇ ਹਨ

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

## Pitfall

OCP ਸ਼ਾਇਕਾਨਾ ਕਰ ਕੇ over-engineering ਬਣ ਜਾਂਦਾ ਹੈ — abstractions ਉਸ variation ਲਈ ਬਣੇ ਹੁੰਦੇ ਹਨ ਜੋ ਕਭੀ ਆਉਂਦਾ ਹੀ ਨਹੀਂ। ਇਸਨੂੰ ਉਹਾਂ ਜਗਾ ਲਾਗੂ ਕਰੋ ਜਿੱਥੇ change *likely* ਹੋ ("rule of three": variation ਅਸਲ ਵਿੱਚ ਆਖ਼ਰ ਨੂੰ abstract ਕਰੋ)।

## ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

Battle-tested ਕੋਡ ਨੂੰ edit ਕਰ ਕੇ feature ਜੋੜਨਾ ਉਸ ਸਭ ਚੀਜ਼ ਵਿੱਚ regression ਦੇ ਜੋਖਮ ਨੂੰ ਵਧਾਂਦਾ ਹੈ ਜੋ ਉਹ ਕੋਡ ਪਹਿਲਾਂ ਹੀ support ਕਰਦਾ ਹੈ; OCP ਨਵੇਂ behavior ਨੂੰ ਨਵੀਆਂ, isolated units ਵਿੱਚ ਸੀਮਤ ਕਰਦਾ ਹੈ।

ਇਹ extensible frameworks ਅਤੇ plugin systems ਦੇ ਪਿਛਲਾ ਸਿਧਾਂਤ ਹੈ — ਅਤੇ ਇਹ LSP 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ substitutable subtypes ਉਹ ਚੀਜ਼ ਹਨ ਜੋ "closed" core ਨੂੰ untouched ਛੱਡਣ ਲਈ safe ਬਣਾਉਂਦੇ ਹਨ।