SOLID yra penki projektavimo principai, skirti kurti tvarias ir lanksčias OOP sistemas. Kiekvienas iš jų sprendžia bendrą standžio, trapaus kodo priežastį.
SOLID yra penki projektavimo principai, skirti kurti tvarias ir lanksčias OOP sistemas. Kiekvienas iš jų sprendžia bendrą standžio, trapaus kodo priežastį.
| Raidė | Principas | Vieno eilutės reikšmė |
|---|
| S | Single Responsibility | Klasė turėtų turėti tik vieną pokytį sukeliančią priežastį |
| O | Open/Closed | Atverta pratęsimui, uždaryta modifikavimui |
| L | Liskov Substitution | Potipiai turi būti naudojami visur, kur naudojamas bazinis tipas |
| I | Interface Segregation | Daug mažų sąsajų geriau nei viena didelė |
| D | Dependency Inversion | Priklausykite abstrakcijų, o ne konkrečių klasių |
# 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 nepriklauso nuo el. pašto konkrečiai — pakeiskite SMS arba testinę kopija jo nepaliesdami (D). Priidėjus naują pranešimiųjimo tipą nereikia keisti OrderService (O).
SOLID yra gidas, o ne dėsnis. Per daug jį taikant — sąsaja kiekvienai klasei, netiesiogiai visur — susidaro „abstrakcijos sriuba", kuri sunkiau suprasti nei išspręsta problema.
SOLID suteikia bendrą diagnostinę kalbą: recenzentai gali pavadinti kodėl klasę sunku keisti ("tai pažeidžia SRP") vietoj to, kad ginčytųsi pagal skonį.
Taikant suvokusiai, šie principai sumažina dėl to žalos sukeliamus efektus — pokyčiai lieka lokalūs, naujos funkcijos pratęsia, o ne perrašo, ir testai gali pakeisti tikrąsias priklausomybes imitacijomis.
IT pokalbių klausimų biblioteka su išsamiais atsakymais — nuo Junior iki Senior.
Paaukoti