SOLID sunt cinci principii de design pentru construirea sistemelor OOP ușor de menținut și flexibile. Fiecare abordează o cauză comună a codului rigid și fragil.
SOLID sunt cinci principii de design pentru construirea sistemelor OOP ușor de menținut și flexibile. Fiecare abordează o cauză comună a codului rigid și fragil.
| Literă | Principiu | Semnificație într-o linie |
|---|
| S | Single Responsibility | O clasă ar trebui să aibă un singur motiv pentru a se schimba |
| O | Open/Closed | Deschisă pentru extensie, închisă pentru modificare |
| L | Liskov Substitution | Subtipurile trebuie să fie utilizabile oriunde este folosit tipul de bază |
| I | Interface Segregation | Multe interfețe mici sunt mai bune decât una mare |
| D | Dependency Inversion | Depinde de abstracții, nu de clase concrete |
# 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 nu depinde de email în mod specific — înlocuiți cu SMS sau un test double fără să o atingeți (D). Adăugarea unui nou tip de notificator nu necesită nicio schimbare în OrderService (O).
SOLID este o orientare, nu o lege. Aplicarea în exces — o interfață per clasă, indirectare peste tot — produce "abstraction soup" care este mai greu de urmărit decât problema pe care a rezolvat-o.
SOLID oferă un limbaj diagnostic comun: recenzenții pot numi de ce o clasă este greu de schimbat ("aceasta încalcă SRP") în loc să dezbată după gust.
Aplicat cu judecată, principiile reduc efectele în cascadă — schimbările rămân locale, noile caracteristici se extind mai degrabă decât se rescriu, și testele pot înlocui falsuri cu dependențe reale.