SOLID är fem designprinciper för att bygga underhållbara, flexibla OOP-system. Varje princip åtgärdar en vanlig orsak till stel, skör kod.
SOLID är fem designprinciper för att bygga underhållbara, flexibla OOP-system. Varje princip åtgärdar en vanlig orsak till stel, skör kod.
| Bokstav | Princip | En-radsmening |
|---|
| S | Single Responsibility | En klass bör ha en anledning att ändras |
| O | Open/Closed | Öppen för utökning, stängd för ändringar |
| L | Liskov Substitution | Subtyper måste vara användbara överallt där bastypen är |
| I | Interface Segregation | Många små gränssnitt slår ett stort |
| D | Dependency Inversion | Bero på abstraktioner, inte konkreta 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 beror inte på e-post specifikt — byt till SMS eller en testdubblöd utan att röra det (D). Att lägga till en ny aviseringstyp kräver ingen ändring av OrderService (O).
SOLID är vägledning, inte lag. Överanvändning — ett gränssnitt per klass, omväg överallt — producerar "abstraktionssoppa" som är svårare att följa än problemet den löste.
SOLID ger ett delat diagnostiskt språk: granskare kan namnge varför en klass är svår att ändra ("detta bryter SRP") istället för att diskutera efter smak.
När principerna tillämpas med omdöme minskar de dalgångseffekter — ändringar förblir lokala, nya funktioner utökar istället för att omskriva, och tester kan ersätta fejkningsmål för riktiga beroenden.