Flup zmierza we właściwym kierunku. „Zasada jednolitej odpowiedzialności” pierwotnie obowiązywała w procedurach. Na przykład Dennis Ritchie powiedziałby, że funkcja powinna zrobić jedną rzecz i zrobić to dobrze. Następnie w C ++ Bjarne Stroustrup powiedziałby, że klasa powinna zrobić jedną rzecz i zrobić to dobrze.
Zauważ, że z wyjątkiem praktycznych reguł, ci dwaj formalnie mają ze sobą niewiele lub nic wspólnego. Zaspokajają tylko to, co jest wygodne do wyrażenia w języku programowania. Cóż, to jest coś. Ale to zupełnie inna historia niż to, do czego zmierza flup.
Nowoczesne implementacje (tj. Zwinne i DDD) skupiają się bardziej na tym, co jest ważne dla biznesu niż na tym, co może wyrazić język programowania. Zaskakujące jest to, że języki programowania jeszcze nie nadrobiły zaległości. Stare języki podobne do FORTRAN przechwytują obowiązki, które pasują do głównych modeli koncepcyjnych tamtych czasów: procesów, które stosowano do każdej karty, gdy przechodziła ona przez czytnik kart, lub (jak w C) przetwarzania towarzyszącego każdemu przerwaniu. Potem pojawiły się języki ADT, które dojrzewały do tego stopnia, że uchwyciły to, co ludzie DDD wymyślili na nowo jako ważne (chociaż Jim Neighbors większość tego zorientowali się, opublikowali i używali do 1968 roku): co dziś nazywamy klasami . (To NIE są moduły.)
Ten krok był mniej ewolucyjny niż wahadło wahadłowe. Gdy wahadło przeszło do danych, straciliśmy modelowanie przypadków użycia właściwe dla FORTRAN. To dobrze, gdy głównym celem są dane lub kształty na ekranie. To świetny model dla programów takich jak PowerPoint, a przynajmniej dla jego prostych operacji.
Zgubiono obowiązki systemowe . Nie sprzedajemy elementów DDD. Nie radzimy sobie z metodami klasowymi. Sprzedajemy obowiązki systemowe. Na pewnym poziomie musisz zaprojektować swój system zgodnie z zasadą jednej odpowiedzialności.
Więc jeśli spojrzysz na ludzi takich jak Rebecca Wirfs-Brock lub ja, którzy mówili o metodach klasowych, teraz rozmawiamy o przypadkach użycia. Właśnie to sprzedajemy. To są operacje systemowe. Przypadek użycia powinien ponosić jedną odpowiedzialność. Przypadek użycia rzadko jest jednostką architektoniczną. Ale wszyscy próbowali udawać, że tak jest. Na przykład obserwuj ludzi SOA.
Dlatego jestem podekscytowany architekturą DCI Trygve'a Reenskauga - tak opisałem powyższą książkę Lean Architecture. W końcu nadaje prawdziwą rangę temu, co kiedyś było arbitralnym i mistycznym posłuszeństwem wobec „pojedynczej odpowiedzialności” - jak można znaleźć w większości powyższych argumentów. Ta postawa odnosi się do ludzkich modeli mentalnych: najpierw użytkownicy końcowi ORAZ programiści na drugim miejscu. Dotyczy problemów biznesowych. I prawie przypadkiem obejmuje zmiany, gdy flup rzuca nam wyzwanie.
Zasada pojedynczej odpowiedzialności, jaką znamy, jest albo dinozaurem pozostałym po jego pochodzeniu, albo koniem hobbystycznym, którego używamy jako substytutu zrozumienia. Musisz zostawić kilka z tych hobby koni, aby zrobić świetne oprogramowanie. A to wymaga myślenia od razu po wyjęciu z pudełka. Utrzymanie prostoty i łatwości zrozumienia działa tylko wtedy, gdy problem jest prosty i łatwy do zrozumienia. Nie interesują mnie te rozwiązania: nie są typowe i nie na tym polega wyzwanie.
