SOLID నిర్వహించదగిన, సరళమైన OOP సిస్టమ్లను నిర్మించడానికి ఐదు డిజైన్ సూత్రాలు. ప్రతిটి కఠిన, నిరుపద్రవ కోడ్ యొక్క సాధారణ కారణాన్ని పరిష్కరిస్తుంది.
SOLID నిర్వహించదగిన, సరళమైన OOP సిస్టమ్లను నిర్మించడానికి ఐదు డిజైన్ సూత్రాలు. ప్రతిটి కఠిన, నిరుపద్రవ కోడ్ యొక్క సాధారణ కారణాన్ని పరిష్కరిస్తుంది.
| అక్షరం | సూత్రం | ఒక-లైన్ అర్థం |
|---|
| S | Single Responsibility | క్లాస్కు మార్పు కోసం ఒక కారణం ఉండాలి |
| O | Open/Closed | సంకలనం కోసం తెరవబడింది, సవరణ కోసం మూసివేయబడింది |
| L | Liskov Substitution | సబ్టైప్లు ఆధారక్లాస్ ఉన్న చోట ఉపయోగించదగినవిగా ఉండాలి |
| I | Interface Segregation | చాలా చిన్న ఇంటర్ఫేస్లు ఒక చిన్న ఒకటి కంటే ఉత్తమం |
| D | Dependency Inversion | నిర్దిష్ట క్లాస్ల కంటే సంగ్రహణలపై ఆధారపడండి |
# 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 లేదా పరీక్ష డబుల్ కోసం దాన్ని తాకకుండా భర్తీ చేయండి (D). కొత్త నోటిఫైయర్ రకాన్ని జోడించడానికి OrderService కి ఎటువంటి మార్పు అవసరం లేదు (O).
SOLID సూచన, చట్టం కాదు. ఎక్కువ వర్తించడం — క్లాస్కు ఇంటర్ఫేస్, ప్రతిచోటా పరోక్ష జీవితం — "సంగ్రహణ సూప్" ను తయారు చేస్తుంది, ఇది దాని సమస్యను పరిష్కరించిన కంటే అనుసరించడం కష్టం.
SOLID ఒక భాగస్వామ్య నిర్ధారణ భాష ఇస్తుంది: సమీక్షకులు క్లాస్ మార్పు కోసం ఎందుకు కష్టమైనది అని పేర్కొనవచ్చు ("ఇది SRP ను ఉల్లంఘిస్తుంది") రుచి ద్వారా వాదించడానికి బదులుగా.
తీర్పుతో వర్తించినప్పుడు, సూత్రాలు సరిపొయ్యే ప్రభావాలను తగ్గిస్తాయి — మార్పులు స్థానిక, కొత్త లక్షణాలు పునరాలోచన విస్తరించండి, మరియు పరీక్షలు నిజమైన ఆధారపడటం కోసం నకిలీలను భర్తీ చేయవచ్చు.