SOLID on viisi suunnittelun periaatetta ylläpidettävien, joustamattomien OOP-järjestelmien rakentamiseen. Jokainen käsittelee yleistä syytä jäykkään, hauraaseen koodiin.
SOLID on viisi suunnittelun periaatetta ylläpidettävien, joustamattomien OOP-järjestelmien rakentamiseen. Jokainen käsittelee yleistä syytä jäykkään, hauraaseen koodiin.
| Kirjain | Periaate | Yhden rivin merkitys |
|---|
| S | Single Responsibility | Luokalla on oltava yksi syy muuttua |
| O | Open/Closed | Avoin laajennukselle, suljettu muutoksille |
| L | Liskov Substitution | Alatyypit on oltava käytettävissä kaikkialla, missä perustyypit ovat |
| I | Interface Segregation | Monet pienet liittymät paremmin kuin yksi iso |
| D | Dependency Inversion | Riipu abstraktioista, ei betoniseista luokista |
# 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 ei ole riippuvainen sähköpostista erityisesti — vaihda SMS:ään tai testituoksuun ilman sitä koskematta (D). Uuden notifier-tyypin lisääminen ei vaadi muutosta OrderServicessa (O).
SOLID on opas, ei laki. Liian laaja soveltaminen — yksi liittymä per luokka, epäsuoria viittauksia kaikkialla — tuottaa "abstraktiota keittoa", jota on vaikeampi seurata kuin ongelmaa, jonka se ratkaisin.
SOLID tarjoaa jaetun diagnostisen kielen: arvioijat voivat nimetä, miksi luokka on vaikea muuttaa ("tämä rikkoo SRP"), sen sijaan että väiteltäisiin makujen perusteella.
Kun periaatteita sovelletaan harkinnalla, ne vähentävät aaltoiluvaikutuksia — muutokset pysyvät paikallisin, uudet ominaisuudet laajenevat uudelleenkirjoituksen sijaan, ja testit voivat korvata väärennökset todellisilla riippuvuuksilla.