SOLID er fem designprincipper til at bygge vedligeholdelses- og fleksible OOP-systemer. Hver behandler en almindelig årsag til stiv, skør kode.
SOLID er fem designprincipper til at bygge vedligeholdelses- og fleksible OOP-systemer. Hver behandler en almindelig årsag til stiv, skør kode.
| Bogstav | Princip | En-linjet betydning |
|---|
| S | Single Responsibility | En klasse bør have én grund til at ændres |
| O | Open/Closed | Åben for udvidelse, lukket for modifikation |
| L | Liskov Substitution | Undertyper skal kunne bruges overalt hvor basistyperne bruges |
| I | Interface Segregation | Mange små grænseflader slår ét federe interface |
| D | Dependency Inversion | Afhæng af abstraktioner, 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 afhænger ikke specifikt af e-mail — skift til SMS eller en testdobbelt uden at røre den (D). Tilføjelse af en ny notifier-type kræver ingen ændring i OrderService (O).
SOLID er vejledning, ikke lov. Over-angivelse — et interface pr. klasse, indirection overalt — producerer "abstraktions-suppe", der er sværere at følge end det problem, det løste.
SOLID giver et delt diagnostisk sprog: reviewers kan navngive hvorfor en klasse er vanskelig at ændre ("dette overtræder SRP") i stedet for at argumentere efter smag.
Når det anvendes med dømmekraft, reducerer principperne ripple-effekter — ændringer forbliver lokale, nye funktioner udvider i stedet for at omskrive, og tests kan erstatte falske for rigtige afhængigheder.