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 ను ఉల్లంఘిస్తుంది") రుచి ద్వారా వాదించడానికి బదులుగా.
తీర్పుతో వర్తించినప్పుడు, సూత్రాలు సరిపొయ్యే ప్రభావాలను తగ్గిస్తాయి — మార్పులు స్థానిక, కొత్త లక్షణాలు పునరాలోచన విస్తరించండి, మరియు పరీక్షలు నిజమైన ఆధారపడటం కోసం నకిలీలను భర్తీ చేయవచ్చు.
జూనియర్ నుండి సీనియర్ వరకు వివరణాత్మక సమాధానాలతో IT ఇంటర్వ్యూ ప్రశ్నల లైబ్రరీ.
విరాళం