Načelo enotne odgovornosti
Načelo enotne odgovornosti je načelo računalniškega programiranja, ki navaja, da bi moral vsak modul, razred ali funkcija prevzeti odgovornost za en del funkcionalnosti, ki jo zagotavlja programska oprema, in to odgovornost mora v celoti zajeti v razred. Vse njegove storitve morjajo biti ozko usklajene s to odgovornostjo. Robert C. Martin izrazi načelo kot: »Razred bi moral imeti samo en razlog za spremembo«, čeprav je zaradi zmede okoli besede »razlog« pred kratkim izjavil, da "to načelo govori o ljudeh. (Deležnik)"
Zgodovina[uredi | uredi kodo]
Izraz je uvedel Robert C. Martin v istoimenskem članku kot del njegovih načel o objektno usmerjenem oblikovanju,[1] ki so postali priljubljeni zaradi knjige Agile Software Development, Principles, Patterns, and Practices.[2] Martin je opisal, da temelji na načelu kohezije, kot sta jo opisala Tom DeMarco v svoji knjigi Strukturirana analiza in sistemska specifikacija[3] ter Meilir Page-Jones v Praktičnem vodniku za oblikovanje strukturiranih sistemov.[4] Leta 2014 je Martin napisal blog z naslovom Načelo enotne odgovornosti Arhivirano 2018-10-08 na Wayback Machine. z namenom pojasniti, kaj je bilo mišljeno z besedno zvezo »razlog za spremembe«.
Primer[uredi | uredi kodo]
Martin definira odgovornost kot »razlog za spremembo« in zaključi, da mora imeti razred ali modul en in izključno en razlog, ki ga je treba spremeniti (tj. prepisati). Zgled je modul, ki sestavlja in natisne poročilo. Tak modul se lahko spremeni iz dveh razlogov: prvič, lahko se spremeni vsebina poročila in drugič, lahko se spremenji njegova oblika. Te dve stvari se spreminjata zaradi zelo različnih vzrokov; prvi je vsebinski in drugi kozmetični. Načelo enotne odgovornosti pravi, da sta ta dva vidika problema v resnici dve ločeni odgovornosti, zato morata biti v ločenih razredih ali modulih. Slaba zasnova bi bila združiti dve stvari, ki se zaradi različnih razlogov spreminjata v različnih obdobjih.
Razlog, zaradi katerega je pomembno, da je razred osredotočen na eno samo skrb, je v tem, da ga to naredi bolj robustnega. Če nadaljujemo s prejšnjim primerom, če pride do spremembe postopka priprave poročil, v primaru da je del istega razreda obstaja večja nevarnost, da se koda, ki tiska, zlomi.
Sklici[uredi | uredi kodo]
- ↑ »The Principles of OOD«. ArticleS.UncleBob. 2005.
- ↑ Martin 2003, str. 95-98
- ↑ DeMarco, Tom. (1979). Structured Analysis and System Specification. Prentice Hall. ISBN 0-13-854380-1.
- ↑ Page-Jones, Meilir (1988). The Practical Guide to Structured Systems Design. Yourdon Press Computing Series. str. 82. ISBN 978-8120314825.