OOP ਵਿਚ abstraction ਕੀ ਹੈ?

Question

Accepted Answer

**Abstraction** ਦਾ ਮਤਲਬ ਹੈ ਕਿ *ਕਿ* ਇਕ object ਕਰਦਾ ਹੈ ਇਹ ਦਿਖਾਉਣਾ ਪਰ *ਕਿਵੇਂ* ਇਹ ਕਰਦਾ ਹੈ ਇਹ ਲੁਕਾ ਦੇਣਾ। ਤੁਸੀਂ ਇਕ ਸਾਧਾਰਨ, ਸਥਿਰ interface ਨਾਲ ਜੁੜਦੇ ਹੋ ਅਤੇ ਇਸਦੇ ਪਿਛਾਂਵ ਦੇ ਉਲਝੇ ਹੋਏ implementation ਨੂੰ ਨਜ਼ਰ ਅੰਦਾਜ਼ ਕਰਦੇ ਹੋ।

## What vs. how

```python
from abc import ABC, abstractmethod

class PaymentGateway(ABC):          # the abstraction: "what"
    @abstractmethod
    def charge(self, amount): ...    # callers only need this contract

class StripeGateway(PaymentGateway): # one "how"
    def charge(self, amount):
        # talk to Stripe's API, handle tokens, retries...
        return f"charged {amount} via Stripe"

class PayPalGateway(PaymentGateway): # another "how"
    def charge(self, amount):
        return f"charged {amount} via PayPal"

def checkout(gateway: PaymentGateway, amount):
    return gateway.charge(amount)    # depends only on the abstraction
```

`checkout` ਕਦੇ ਨਹੀਂ ਜਾਣਦਾ ਕਿ ਇਹ Stripe ਹੈ ਜਾਂ PayPal — ਇਹ charging ਦੇ *ਵਿਚਾਰ* 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਨਾ ਕਿ ਵਿਉਰੀ 'ਤੇ।

## Abstraction vs. encapsulation

ਇਹ ਸਬੰਧਤ ਹਨ ਪਰ ਵੱਖਰੇ ਹਨ: **encapsulation** state ਨੂੰ ਲੁਕਾ ਦਿੰਦਾ ਹੈ ਇਸਨੂੰ ਸੁਰੱਖਤ ਰੱਖਣ ਲਈ; **abstraction** complexity ਨੂੰ ਲੁਕਾ ਦਿੰਦਾ ਹੈ interface ਨੂੰ ਸਰਲ ਕਰਨ ਲਈ। Encapsulation *ਸੁਰੱਖਿਆ* ਬਾਰੇ ਹੈ; abstraction *ਕੀ ਦਿਖਾਉਣਾ ਹੈ* ਇਸ ਬਾਰੇ ਹੈ।

## Pitfall

Leaky abstractions (ਜਿਥੇ implementation ਦੀਆਂ ਵਿਉਰੀਆਂ ਭੀ ਸਾਹਮਣੇ ਆ ਜਾਣ) ਅਤੇ premature abstractions (ਸਮੱਸਿਆ ਨੂੰ ਸਮਝਣ ਤੋਂ ਪਹਿਲੇ ਬਣਾਏ ਗਏ) ਦੋਵੇਂ ਨੁਕਸਾਨ ਕਰਦੇ ਹਨ। ਉਹ ਚੀਜ਼ਾਂ abstract ਕਰੋ ਜੋ ਸੱਚਮੁੱਚ ਵੱਖਰੀਆਂ ਹੁੰਦੀਆਂ ਹਨ।

## ਇਹ ਕਿਉਂ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ

Abstraction ਉਹ ਹੈ ਜਿਸ ਦੁਆਰਾ ਤੁਸੀਂ complexity ਨੂੰ ਕਾਬੂ ਵਿਚ ਲਿਆ ਦਿੰਦੇ ਹੋ: callers ਪੂਰੇ subsystem ਦੀ ਬਜਾਏ ਇਕ ਛੋਟੇ interface ਬਾਰੇ ਸੋਚਦੇ ਹਨ।

ਇਹ implementations ਨੂੰ swap ਕਰਨਾ ਸੰਭਵ ਬਣਾਉਂਦਾ ਹੈ — ਇਕ ਨਵਾਂ payment provider ਸ਼ਾਮਲ ਕਰਨਾ ਸਿਰਫ਼ ਇਕ class ਨੂੰ ਟਾਂਚਦਾ ਹੈ, ਹਰ caller ਨੂੰ ਨਹੀਂ — ਜੋ flexible, testable design ਦੀ ਬੁਨਿਆਦ ਹੈ।