Princip jedné odpovědnosti ( SRP ) je princip OOP , což znamená , že každý objekt musí mít jednu odpovědnost a tato odpovědnost musí být zcela zapouzdřena do třídy . Veškeré jeho jednání musí směřovat výhradně k zajištění této odpovědnosti.
Třída by měla mít pouze jeden důvod ke změně.Robert C. Martin
Termín SRP zavedl Robert S. Martin ve stejnojmenném článku jako součást SOLID , který zpopularizovala jeho kniha Rapid Software Development. Principy, příklady, praxe.“ [1] . Martin popsal SRP na základě vzoru popsaného Tomem DeMarcem [2] a Mailerem Page-Jonesem [3] nazvaným konektivita .
V SOLID je písmeno „S“ zkratkou pro Princip jednotné odpovědnosti.
Martin definuje odpovědnost jako důvod změny a dochází k závěru, že třídy by měly mít jediný důvod ke změně. Představte si například třídu, která napíše a vytiskne zprávu. Taková třída se může změnit ze dvou důvodů:
Logicky jsou oba aspekty těchto příčin ve skutečnosti dvě různé odpovědnosti. SRP říká, že v tomto případě musíte třídu rozdělit na dvě nové třídy, které budou charakterizovány pouze jednou odpovědností. Důvodem, proč je důležité udržovat hodiny zaměřené na jediný účel, je to, že jsou hodiny zdravější. Pokud jde o třídu výše, pokud došlo ke změně v procesu sestavování sestavy, je vysoká pravděpodobnost, že kód zodpovědný za tisk se stane nepoužitelným.
Při navrhování různých chování pro stejnou třídu se často objevuje „ objekt Boha “, který je v OOP považován za anti -vzor . Dodržování principu jednotné odpovědnosti se vyhýbá tomuto protivzorku.
Nabízí se otázka, kdy se vyplatí tento princip používat? Princip však není zákon a SRP by se měl uplatňovat v závislosti na tom, jak se aplikace mění :
Slepé dodržování principu jediné odpovědnosti vede k nadměrné složitosti aplikace, její podpory a testování. SRP by měl být používán pouze v případě záruky. Princip SRP lze použít pouze tehdy, když:
Upevňování odpovědností je běžnou praxí a není na tom nic špatného, pokud se snadno udržuje. Dodržování principu jediné odpovědnosti závisí na funkcích softwarového produktu a je nejobtížnější při navrhování aplikací.
ActiveRecord je často uváděn jako příklad porušení SRP , což je vzor, který vám umožňuje snadno propojit data objektů a data z databáze. V ActiveRecord je mnoho povinností soustředěno na jednom místě, a proto lze tvrdit, že ActiveRecord porušuje SRP a stává se tak anti-vzorcem. [4] V některých případech je toto tvrzení diskutabilní, jelikož samotný objekt, který implementuje ActiveRecord, neobsahuje žádnou obchodní logiku, ale poskytuje tabulku z databáze, má pouze jeden důvod pro změnu (změnu tabulky), který nemá nejsou v rozporu s definicí principu SRP [5] [6] .
Následující techniky vám umožňují dodržovat zásadu jediné odpovědnosti:
Klasickým příkladem [7] porušení SRP je situace, kdy se systém obchodních pravidel ( BRMS ) potřebuje vypořádat s trvalým úložištěm ( Persistence ). V prvních fázích návrhu takových systémů je vytvořena třída, která zpracovává obchodní pravidla a obsahuje logiku pro práci s databází. Při porušení SRP se objevují známky špatného projektu , jako například:
Pokud byl systém původně vyvinut prostřednictvím testování ( TDD ), pak tento problém nemusel nastat. Na základě testů si vývojáři rychle dokážou představit, jakou funkcionalitu uživatel potřebuje. Detaily třídy se tedy objevují dlouho před konečnou implementací řešení, čímž ovlivňují návrh vyvíjeného systému. Stává se ale také, že testem řízený vývoj nevede k použití vzoru Class Extraction , poté je systém refaktorován pomocí vzorů Facade , DAO nebo Proxy .
SRP navrhuje rozdělit generické třídy na konkrétní, díky čemuž budou jednoduché a snadno se udržují. Podobnou myšlenku předkládá také princip KISS [8] .