SOLID öt tervezési elv a karbantartható, rugalmas OOP rendszerek felépítéséhez. Mindegyik egy közös okot kezel a merev, törékenyen kódnak.
| Betű | Elv | Egy soros jelentés |
|---|
| S | Egyetlen felelősség | Egy osztálynak csak egy oka lehet a megváltoztatásra |
| O | Nyitott/Zárt | Nyitott a kiterjesztésre, zárt a módosításra |
| L | Liskov helyettesítés | Az altípusoknak használhatónak kell lenniük, ahol az alaptípus |
| I | Interfész szegmentálás | Sok kis interfész jobb, mint egy nagy |
| D | Függőség inverziója | Az absztrakciókra támaszkodjunk, nem a konkrét osztályokra |
# 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
A OrderService nem függ kifejezetten az e-mailtől — helyettesítsen SMS-t vagy tesztet anélkül, hogy megérintené (D). Egy új értesítési típus hozzáadása nem igényel semmilyen módosítást a OrderService-en (O).
SOLID útmutatás, nem törvény. Túl alkalmazása — egy interfész osztályonként, indirekcióa mindenhol — "absztrakciólevest" termel, amely nehezebb követni, mint a megoldott probléma.
SOLID közös diagnosztikai nyelvezetet biztosít: az értékelők megnevezhetik miért nehéz egy osztályt megváltoztatni ("ez megsért egy SRP") ízléssel vitatkozva helyett.
Megfontoláson alapuló alkalmazása során az elvek csökkentik a hullámzási hatásokat — a módosítások helyiek maradnak, az új funkciók kiterjesztik ahelyett, hogy újraíródnának, és a tesztek helyettesíthetik az igazi függőségeket.