SOLID er fem designprinsipper for å bygge vedlikeholdbar, fleksibel objektorientert kode. Hvert prinsipp adresserer en vanlig årsak til stiv, skjør kode.
SOLID er fem designprinsipper for å bygge vedlikeholdbar, fleksibel objektorientert kode. Hvert prinsipp adresserer en vanlig årsak til stiv, skjør kode.
| Bokstav | Prinsipp | Betydning på én linje |
|---|
| S | Single Responsibility | En klasse bør ha én grunn til å endre seg |
| O | Open/Closed | Åpen for utvidelse, lukket for modifikasjon |
| L | Liskov Substitution | Subtyper må kunne brukes hvor basistypen brukes |
| I | Interface Segregation | Mange små grensesnitt er bedre enn ett stort |
| D | Dependency Inversion | Avheng av abstraksjoner, ikke konkrete klasser |
# 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 er ikke avhengig av e-post spesifikt — bytt til SMS eller en test-dobbel uten å ta i den (D). Å legge til en ny notifier-type krever ingen endring i OrderService (O).
SOLID er veiledning, ikke lov. For mye bruk av det — ett grensesnitt per klasse, indireksjon overalt — produserer "abstraction soup" som er vanskeligere å følge enn problemet det løste.
SOLID gir et delt diagnostisk språk: anmeldere kan navngi hvorfor en klasse er vanskelig å endre ("dette bryter SRP") i stedet for å diskutere smak.
Brukt med dømmekraft, reduserer prinsippene ringvirkninger — endringer holdes lokale, nye funksjoner utvider i stedet for å omskrive, og tester kan erstatte falske dobbeltgjengere for virkelige avhengigheter.