Zasada pojedynczej odpowiedzialności

Zasada pojedynczej odpowiedzialności ( SRP ) to zasada programowania komputerowego, która mówi, że „moduł powinien być odpowiedzialny przed jednym i tylko jednym aktorem”. Termin aktor odnosi się do grupy (składającej się z jednego lub większej liczby interesariuszy lub użytkowników), która wymaga zmiany w module.

Robert C. Martin , twórca tego terminu, wyraża tę zasadę w następujący sposób: „Klasa powinna mieć tylko jeden powód do zmiany”. Z powodu zamieszania wokół słowa „powód” wyjaśnił również, że „zasada dotyczy ludzi”. W niektórych swoich wystąpieniach argumentuje również, że zasada dotyczy w szczególności ról lub aktorów. Na przykład, chociaż mogą to być te same osoby, rola księgowego różni się od roli administratora bazy danych. Dlatego każdy moduł powinien być odpowiedzialny za każdą rolę.

Historia

Termin ten został wprowadzony przez Roberta C. Martina w jego artykule „The Principles of OOD” jako część jego Zasad projektowania zorientowanego obiektowo , spopularyzowanych w jego książce Agile Software Development, Principles, Patterns, and Practices z 2003 roku . Martin opisał to jako oparte na zasadzie spójności , jak opisał Tom DeMarco w swojej książce Structured Analysis and System Specification oraz Meilir Page-Jones w The Practical Guide to Structured Systems Design . W 2014 roku Martin opublikował post na blogu zatytułowany „Zasada pojedynczej odpowiedzialności”, którego celem było wyjaśnienie, co oznacza wyrażenie „powód zmiany”. [1]

Przykład

Martin definiuje odpowiedzialność jako powód do zmiany i dochodzi do wniosku, że klasa lub moduł powinien mieć jeden i tylko jeden powód do zmiany (np. przepisania).

Jako przykład rozważmy moduł, który kompiluje i drukuje raport. Wyobraź sobie, że taki moduł można zmienić z dwóch powodów. Po pierwsze, treść raportu może ulec zmianie. Po drugie, format raportu może ulec zmianie. Te dwie rzeczy zmieniają się z różnych przyczyn. Zasada pojedynczej odpowiedzialności mówi, że te dwa aspekty problemu są tak naprawdę dwoma oddzielnymi obowiązkami i dlatego powinny być umieszczone w oddzielnych klasach lub modułach. Łączenie dwóch rzeczy, które zmieniają się z różnych powodów w różnym czasie, byłoby złym projektem .

Powodem, dla którego ważne jest, aby klasa skupiała się na jednym problemie, jest to, że czyni to klasę bardziej niezawodną. Kontynuując powyższy przykład, jeśli nastąpi zmiana w procesie kompilacji raportu, istnieje większe niebezpieczeństwo, że kod drukowania ulegnie uszkodzeniu, jeśli jest częścią tej samej klasy.

Zobacz też

Wzór łańcucha odpowiedzialności
Sprzęganie (programowanie komputerowe)
GRASP (projektowanie obiektowe)
Ukrywanie informacji
SOLIDNY – litera „S” w słowie „SOLIDNY” oznacza zasadę pojedynczej odpowiedzialności
Rozdzielenie obaw

^ Martin, Robert C. (2018). Czysta architektura: przewodnik dla rzemieślników po strukturze i projektowaniu oprogramowania . Boston. ISBN 978-0-13-449432-6 . OCLC 1003645626 .
^ Martin, Robert C. (2003). Zwinne tworzenie oprogramowania, zasady, wzorce i praktyki . Sala Prentice'a. P. 95. ISBN 978-0135974445 .
^ Martin, Robert C. (2014). „Zasada pojedynczej odpowiedzialności” . Blog o czystym kodzie . {{ cite web }} : CS1 maint: stan adresu URL ( link )
Bibliografia _ Czysta architektura: przewodnik rzemieślnika po strukturze i projektowaniu oprogramowania . Sala Prentice'a. ISBN 978-0-13-449416-6 .
^ Martin, Robert C. (2005). „Zasady OOD” . butunclebob.com . {{ cite web }} : CS1 maint: stan adresu URL ( link )
^ Martin 2003 , s. 95–98
Bibliografia _ (1979). Analiza strukturalna i specyfikacja systemu . Sala Prentice'a . ISBN 0-13-854380-1 .
^ Page-Jones, Meilir (1988). Praktyczny przewodnik po projektowaniu systemów strukturalnych . Seria komputerowa Yourdon Press. P. 82. ISBN 978-8120314825 .

Linki zewnętrzne

„ Zasady OOD ” Roberta Martina
„ Zasada pojedynczej odpowiedzialności ” Roberta Martina

[1] Martin, Robert C. (2018). Czysta architektura: przewodnik dla rzemieślników po strukturze i projektowaniu oprogramowania . Boston. ISBN 978-0-13-449432-6 . OCLC 1003645626 .

[cleancode-2] Martin, Robert C. (2003). Zwinne tworzenie oprogramowania, zasady, wzorce i praktyki . Sala Prentice'a. P. 95. ISBN 978-0135974445 .

[3] Martin, Robert C. (2014). „Zasada pojedynczej odpowiedzialności” . Blog o czystym kodzie . {{ cite web }} : CS1 maint: stan adresu URL ( link )

[Martin2018-4] Bibliografia _ Czysta architektura: przewodnik rzemieślnika po strukturze i projektowaniu oprogramowania . Sala Prentice'a. ISBN 978-0-13-449416-6 .

[5] Martin, Robert C. (2005). „Zasady OOD” . butunclebob.com . {{ cite web }} : CS1 maint: stan adresu URL ( link )

[6] Martin 2003 , s. 95–98

[7] Bibliografia _ (1979). Analiza strukturalna i specyfikacja systemu . Sala Prentice'a . ISBN 0-13-854380-1 .

[8] Page-Jones, Meilir (1988). Praktyczny przewodnik po projektowaniu systemów strukturalnych . Seria komputerowa Yourdon Press. P. 82. ISBN 978-8120314825 .