Jedna odpowiedzialność może nie być czymś, co może spełnić jedna funkcja.
class Location {
public int getX() {
return x;
}
public int getY() {
return y;
}
}
Ta klasa może złamać zasadę jednej odpowiedzialności. Nie dlatego, że ma dwie funkcje, ale jeśli koduje getX()i getY()musi zadowolić różnych interesariuszy, którzy mogą wymagać zmian. Jeśli wiceprezydent Pan X rozsyła notatkę, że wszystkie liczby powinny być wyrażone jako liczby zmiennoprzecinkowe, a dyrektor ds. Rachunkowości pani Y nalega, aby wszystkie liczby, które ocenia jej departament, pozostały liczbami całkowitymi, niezależnie od tego, co pan X uważa za dobre, to ta klasa powinna mieć jeden pomysł na to, za kogo jest on odpowiedzialny, ponieważ sprawy stają się mylące.
Gdyby przestrzegano SRP, byłoby jasne, czy klasa Lokacji przyczynia się do rzeczy, na które narażony jest Pan X i jego grupa. Wyjaśnij, za co klasa jest odpowiedzialna, a wiesz, która dyrektywa wpływa na tę klasę. Jeśli oba wpływają na tę klasę, to została źle zaprojektowana, aby zminimalizować wpływ zmiany. „Klasa powinna mieć tylko jeden powód do zmiany” nie oznacza, że cała klasa może zrobić tylko jedną małą rzecz. Oznacza to, że nie powinienem być w stanie spojrzeć na klasę i powiedzieć, że zarówno pan X, jak i pani Y są zainteresowani tą klasą.
Inne niż takie rzeczy. Nie, wiele metod jest w porządku. Po prostu nadaj mu nazwę, która wyjaśnia, które metody należą do klasy, a które nie.
SRP wuja Boba bardziej dotyczy prawa Conwaya niż prawa Curly'ego . Wujek Bob opowiada się za zastosowaniem prawa Curly'ego (zrób jedną rzecz) do funkcji, a nie klas. SRP przestrzega przed mieszaniem powodów do wspólnej zmiany. Prawo Conwaya mówi, że system będzie śledził przepływ informacji w organizacji. To prowadzi do przestrzegania SRP, ponieważ nie obchodzi Cię to, o czym nigdy nie słyszysz.
„Moduł powinien być odpowiedzialny przed jednym i tylko jednym aktorem”
Robert C Martin - Czysta architektura
Ludzie wciąż chcą, aby SRP dotyczyło każdego powodu ograniczenia zakresu. Jest więcej powodów do ograniczenia zakresu niż SRP. Ponadto ograniczam zakres, nalegając, aby klasa była abstrakcją, która może przyjąć nazwę zapewniającą, że zaglądanie do środka nie zaskoczy Cię .
Możesz zastosować Prawo Curly'ego do zajęć. Jesteś poza tym, o czym mówi wujek Bob, ale możesz to zrobić. Jeśli pomylisz się, zaczniesz myśleć, że oznacza to jedną funkcję. To tak, jakby myśleć, że rodzina powinna mieć tylko jedno dziecko. Posiadanie więcej niż jednego dziecka nie powstrzymuje go od bycia rodziną.
Jeśli zastosujesz prawo Curly'ego do klasy, wszystko w klasie powinno dotyczyć jednej idei jednoczącej. Ten pomysł może być szeroki. Chodzi o wytrwałość. Jeśli są tam jakieś funkcje rejestrowania, są one wyraźnie nie na miejscu. Nie ma znaczenia, czy pan X jest jedynym, który dba o ten kod.
Klasyczna zasada, którą należy tu zastosować, nazywa się oddzieleniem obaw . Jeśli oddzielisz wszystkie swoje obawy, można argumentować, że to, co zostało w jednym miejscu, jest jednym z nich. Tak nazwaliśmy ten pomysł, zanim film City Slickers z 1991 roku przedstawił nam postać Curly.
To jest w porządku. Po prostu to, co wujek Bob nazywa odpowiedzialnością, nie jest problemem. Na nim nie spoczywa odpowiedzialność. To coś, co może zmusić cię do zmiany. Możesz skupić się na jednym problemie i nadal tworzyć kod, który będzie odpowiedzialny przed różnymi grupami ludzi o różnych programach.
Może nie obchodzi cię to. W porządku. Myślenie, że trzymanie się „robienia jednej rzeczy” rozwiąże wszystkie wasze problemy projektowe, pokazuje brak wyobrażenia o tym, czym może być „jedna rzecz”. Innym powodem ograniczenia zakresu jest organizacja. Możesz zagnieździć wiele „jednej rzeczy” w innych „jednej rzeczy”, dopóki nie pojawi się szuflada śmieci pełna wszystkiego. Mówiłem o tym wcześniej
Oczywiście klasycznym powodem OOP do ograniczenia zakresu jest to, że klasa ma w nim prywatne pola, a zamiast tego używają getterów do dzielenia się tymi danymi, umieszczamy każdą metodę, która potrzebuje tych danych w klasie, w której mogą używać danych prywatnie. Wielu uważa, że jest to zbyt restrykcyjne, aby używać go jako ogranicznika zakresu, ponieważ nie każda metoda, która należy do siebie, używa dokładnie tych samych pól. Chciałbym zapewnić, że jakikolwiek pomysł, który połączył dane, był tym samym pomysłem, który połączył metody.
Sposób funkcjonalny spojrzeć na to, że a.f(x)i a.g(x)po prostu f a (x) i g (x). Nie dwie funkcje, ale kontinuum par funkcji, które się różnią. Nie musi nawet zawierać danych. Może to być po prostu jak wiesz, który i realizacja masz zamiar użyć. Funkcje, które zmieniają się razem, należą do siebie. To dobry stary polimorfizm.afg
SRP jest tylko jednym z wielu powodów ograniczenia zakresu. Ten jest dobry. Ale nie jedyny.