Czy SRP (zasada pojedynczej odpowiedzialności) jest obiektywny?

Rozważ dwóch projektantów interfejsu użytkownika, którzy chcą zaprojektować „atrakcyjne dla użytkownika” projekty. „Przyciąganie użytkownika” to koncepcja, która nie jest obiektywna i dotyczy wyłącznie projektantów. W ten sposób projektant A mógłby na przykład wybrać czerwony kolor, podczas gdy projektant B wybiera niebieski. Projektant A utwórz układ zupełnie inny niż projektant B i tak dalej.

Czytałem o SRP (Zasada Pojedynczej Odpowiedzialności) i zrozumiałem, że to rodzaj subiektywnej analizy lub podziału obowiązków, które mogą różnić się od projektanta OO do innego projektanta OO. Czy mam rację? Innymi słowy, czy możliwe jest posiadanie dwóch doskonałych analizatorów obiektowych i projektantów, którzy zaproponują dwa różne projekty dla jednego systemu opartego na zasadzie SRP?

Dobre pytanie, na które często się zastanawiałem.

Powiedziałbym, że nie jest obiektywny, nie. Zdecydowanie subiektywne. To, jak podejdziesz do rozwiązywania problemów, zależy od twojej filozofii dotyczącej tego rodzaju problemów. Nauka pokazuje nam, że istnieje wiele różnych sposobów skutecznego rozwiązania tego samego problemu. Nauka pokazuje nam również, że ludzie z różnych kontynentów mogą niezależnie opracowywać te same rozwiązania, dlatego niektóre rozwiązania są bardziej oczywiste niż inne. W każdym razie, ocenianie rozwiązań pod kątem „najlepszego” zależy od twoich kryteriów.

Naprawdę, to, co można postrzegać jako dwie części tej samej całości, inne może postrzegać jako dwie całkowicie odrębne koncepcje. Cały czas widać to, gdy patrzymy na to, jak opiekunowie różnych bibliotek kodów podchodzą do tego samego problemu. A jednak oba rozwiązania działają dobrze.

(PS. Zredagowałem tę odpowiedź, gdy ostatnie pytanie PO zawiera pytanie przeciwne do tytułu pytania).

Sama zasada jest obiektywna, ale istnieje tak wiele różnych sposobów implementacji czegoś, co jest zgodne z tą zasadą, że dwóch niezależnych programistów prawie zawsze zaproponuje dość różne projekty systemów dla tej samej aplikacji.

Jest nawet prawdopodobne, że ten sam programista wykonujący ten sam projekt dwa razy, nadal będzie oferował dwa rozwiązania, które przynajmniej częściowo się różnią.

Aby zasada powodowała, że ​​projekty systemów zawsze wyglądały tak samo, musiałaby obejmować każdy aspekt decyzji projektowych. Jedna główna odpowiedzialność obejmuje tylko niewielką część decyzji projektowych związanych z tworzeniem dowolnego projektu systemu.

Zastosowanie tej zasady jest subiektywne. Jednak „subiektywne” nie oznacza „preferencji” w taki sam sposób, jak robi to estetyka.

Istnieją oczywiste skrajności. Klasa z dokładnie jedną metodą, zawierającą tylko kilka wierszy kodu, która nie wywołuje żadnych innych klas, zdecydowanie podąża za SRP. Z drugiej strony klasa z dwiema metodami, z których jedna zawiera pełną implementację poczty e-mail za pośrednictwem surowych gniazd, a druga, która tworzy formularz GUI, zdecydowanie nie przestrzega SRP.

Estetyka to kiepska analogia. Lepszą analogią byłyby dobrze znane koncepcje sprzężenia i spójności w dziedzinie informatyki . Żaden z nich nie jest atrybutem czarno-białym, prawdziwym lub fałszywym. Jednak oni są mierzalne, nawet jeśli istnieje element jakościowy. Jeśli pokażesz grupie doświadczonych programistów dwa oddzielne projekty dla tej samej funkcji, podadzą podobne odczyty, w których projekt ma więcej sprzężeń i / lub spójności.

W rzeczywistości SRP to zasadniczo tylko funkcjonalna spójność. Mówi, że części jakiegoś modułu (np. Klasy) powinny być zgrupowane razem, ponieważ wszystkie one przyczyniają się do wykonywania tej samej funkcji i bez żadnego innego powodu. „Funkcja” może podlegać interpretacji - niektóre osoby mogą interpretować to dosłownie jako deklarację pojedynczej funkcji (lub metody lub procedury) , inne mogą cofnąć się nieco i myśleć o funkcji jako „wysyłaniu wiadomości e-mail” lub „odtwarzaniu muzyki” , ale wciąż jest tylko tyle miejsca do manewru. „Zarządzanie materiałami” nie jest prawidłowym opisem funkcjonalnym.

Istnieje obiektywna definicja „odpowiedzialności” jako „powodu do zmiany”. W czasie programowania wszystkie powody zmiany leżą w przyszłości, więc programista może zgadywać tylko na podstawie swojego doświadczenia i wiedzy w dziedzinie. Zatem analiza obowiązków jest rodzajem prognozy, częściowo subiektywnej.

SRP jest obiektywny; wdrożenia są subiektywne

dwie implementacje o dokładnie takiej samej funkcjonalności mogą wykorzystywać całkowicie różne struktury wewnętrzne, co skutkuje różnymi klasami i metodami, i obie mogą spełniać SRP

jeśli użyją tych samych metod i stanu i oba będą znormalizowane (minimalne / nieredundantne), to teoretycznie skończą z tymi samymi klasami i metodami w ramach SRP.

ale nie mogę tego udowodnić. Jeszcze.