SOLID ਰੱਖ-ਰਖਾਅ ਕਰਨ ਯੋਗ, ਲਚਕਦਾਰ OOP ਸਿਸਟਮ ਬਣਾਉਣ ਲਈ ਪੰਜ ਡਿਜ਼ਾਈਨ ਸਿਧਾਂਤ ਹਨ। ਹਰ ਇੱਕ ਕਠੋਰ, ਨਾਜ਼ੁਕ ਕੋਡ ਦੇ ਆਮ ਕਾਰਨ ਨੂੰ ਸੰਬੋਧਿਤ ਕਰਦਾ ਹੈ।
| ਅੱਖਰ | ਸਿਧਾਂਤ | ਇੱਕ-ਲਾਈਨ ਮਤਲਬ |
|---|
| S | Single Responsibility | ਇੱਕ ਕਲਾਸ ਦਾ ਬਦਲਣ ਦਾ ਇੱਕ ਕਾਰਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ |
| O | Open/Closed | ਵਿਸਤਾਰ ਲਈ ਖੁੱਲਾ, ਸੋਧ ਲਈ ਬੰਦ |
| L | Liskov Substitution | Subtypes ਨੂੰ ਉਹਨਾਂ ਜਗ੍ਹਾ ਉਪਯੋਗ ਕਰਨ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿੱਥੇ ਆਧਾਰ ਕਿਸਮ ਵਰਤੀ ਜਾਂਦੀ ਹੈ |
| I | Interface Segregation | ਬਹੁਤ ਸਾਰੀਆਂ ਛੋਟੀਆਂ interfaces ਇੱਕ ਮੋਟੀ ਨਾਲੋਂ ਬਿਹਤਰ ਹਨ |
| D | Dependency Inversion | abstractions ਤੇ ਨਿਰਭਰ ਕਰੋ, concrete classes ਤੇ ਨਹੀਂ |
# Dependency Inversion: high-level code depends on an abstraction
class Notifier: # abstraction
def send(self, msg): ...
class EmailNotifier(Notifier):
def send(self, msg): print("email:", msg)
class OrderService:
def __init__(self, notifier: Notifier): # injected abstraction
self.notifier = notifier # not "new EmailNotifier()"
def place(self):
self.notifier.send("order placed") # works with ANY Notifier
OrderService ਈ-ਮੇਲ ਤੇ ਖਾਸ ਤੌਰ ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਹੈ — ਇਸਨੂੰ ਛੂਏ ਬਿਨਾਂ SMS ਜਾਂ ਇੱਕ ਟੈਸਟ double ਨਾਲ ਬਦਲੋ (D)। ਇੱਕ ਨਵੀਂ notifier ਕਿਸਮ ਜੋੜਨ ਨੂੰ OrderService ਵਿੱਚ ਕੋਈ ਬਦਲਾਵ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ (O)।
SOLID ਨਿਰਦੇਸ਼ ਹੈ, ਕਾਨੂੰਨ ਨਹੀਂ। ਇਸਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਲਾਗੂ ਕਰਨਾ — ਪ੍ਰਤਿ ਕਲਾਸ ਇੱਕ interface, ਹਰ ਜਗ੍ਹਾ indirection — "abstraction soup" ਪੈਦਾ ਕਰਦਾ ਹੈ ਜੋ ਸਮੱਸਿਆ ਤੋਂ ਜ਼ਿਆਦਾ ਪਿੱਛਾ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ।
SOLID ਇੱਕ ਸਾਂਝੀ ਤਸ਼ਖੀਸ ਵਾਲੀ ਭਾਸ਼ਾ ਦਿੰਦਾ ਹੈ: ਸਮੀਖਿਆਕਾਰ ਕਿਉਂ ਕਿਸੇ ਕਲਾਸ ਨੂੰ ਬਦਲਨਾ ਮੁਸ਼ਕਲ ਹੈ ("ਇਹ SRP ਦੀ ਉਲੰਘਣਾ ਕਰਦਾ ਹੈ") ਸਵਾਦ ਤੋਲਣ ਦੀ ਬਜਾਏ ਨਾਮ ਦੇ ਸਕਦੇ ਹਨ।
ਸੋਚ-ਸਮਝ ਨਾਲ ਲਾਗੂ ਕਰਦੇ ਹੋਏ, ਸਿਧਾਂਤ ripple effects ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ — ਬਦਲਾਵ ਸਥਾਨਕ ਰਹਿੰਦੇ ਹਨ, ਨਵੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਲਿਖਣ ਦੀ ਬਜਾਏ ਵਿਸਤਾਰ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਟੈਸਟ ਅਸਲ ਨਿਰਭਰਤਾਵਾਂ ਲਈ fakes ਨੂੰ ਬਦਲ ਸਕਦੀਆਂ ਹਨ।
ਵਿਸਤ੍ਰਿਤ ਜਵਾਬਾਂ ਨਾਲ IT ਇੰਟਰਵਿਊ ਸਵਾਲਾਂ ਦੀ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ — ਜੂਨੀਅਰ ਤੋਂ ਸੀਨੀਅਰ ਤੱਕ।
ਦਾਨ ਕਰੋ