Różnica między zasadą pojedynczej odpowiedzialności a oddzieleniem problemów

Jaka jest różnica między zasadą pojedynczej odpowiedzialności a oddzieleniem problemów?

Zasada pojedynczej odpowiedzialności (SRP) - daj każdej klasie tylko jeden powód do zmiany; oraz „Powód zmiany” == „odpowiedzialność”. Na przykład: Klasa faktury nie ma obowiązku samodzielnego drukowania.

Separacja problemów (od 1974). Obawa == cecha systemu. Dbanie o każdy z problemów: dla każdego z nich inne obawy są nieistotne. Ukrywanie realizacji zachowania.

Od tutaj .

Moim zdaniem Zasada Pojedynczej Odpowiedzialności jest jednym z narzędzi / idiomów do osiągnięcia Rozdzielenia Obaw.

Rozdzielenie obaw a zasada pojedynczej odpowiedzialności (SoC vs SRP)

Z połączonego artykułu:

Separacja problemów (SoC) - to proces polegający na rozbiciu programu komputerowego na odrębne cechy, które w jak najmniejszym stopniu pokrywają się pod względem funkcjonalności. Niepokój to jakikolwiek element zainteresowania lub przedmiotu programu. Zazwyczaj obawy są synonimami funkcji lub zachowań. http://en.wikipedia.org/wiki/Separation_of_concerns

Zasada pojedynczej odpowiedzialności (SRP) - każdy obiekt powinien mieć jedną odpowiedzialność, a wszystkie jego usługi powinny być ściśle powiązane z tą odpowiedzialnością. Na pewnym poziomie spójność jest uważana za synonim SRP. http://en.wikipedia.org/wiki/Single_responsibility_principle

Pojedyncza odpowiedzialność określa, że ​​obiekt jest odpowiedzialny za pojedynczą jednostkę pracy.

Separacja obaw stanowi, że aplikacje powinny być podzielone na moduły, których funkcjonalności w jak najmniejszym stopniu się pokrywają.

Podobne wyniki końcowe ... nieco inne zastosowania.

Zasada pojedynczej odpowiedzialności i oddzielenie problemów to tak naprawdę to samo.

Jasne, możesz ugrzęznąć w akademickiej dyskusji, próbując wydobyć jakąś różnicę między nimi, ale dlaczego? Pod każdym względem opisują to samo. Największym problemem jest to, że ludzie są tak pochłonięci chęcią dokładnego poznania „troski” i „odpowiedzialności”, że być może brakuje im ważnej idei stojącej za SRP i SoC.

Pomysł polega po prostu na podzieleniu bazy kodu na luźno powiązane, odizolowane części. Pozwala to wielu programistom pracować nad różnymi częściami bez wpływu na siebie nawzajem, a także pozwala jednemu deweloperowi modyfikować jedną izolowaną część bez przerywania innej.

Jest to stosowane na poziomie modułu, np. MVC to wzorzec architektoniczny promujący SRP i SoC. Baza kodu jest podzielona na izolowane modele, widoki i kontrolery. W ten sposób modyfikacja widoku może odbywać się niezależnie od modelu. Dwa dwa nie są ze sobą przerażająco powiązane.

Na niższym poziomie powinno to dotyczyć również zajęć. Zamiast umieszczać dziesiątki metod w jednej klasie, podziel kod na kilka. Z tych samych powodów.

Nawet na poziomie metody podziel duże metody na mniejsze metody.

Zasadniczo. SRP to zasada, a nie reguła, więc nie musisz (czytaj: nie wolno / nie wolno) podążać za nią religijnie do skrajności. Nie oznacza to pójścia za daleko i posiadania na przykład tylko jednej metody siedmioliniowej w każdej klasie. Oznacza to po prostu ogólną zasadę dzielenia kodu na pojedyncze części. Chodzi o to, że doprowadzi to do lepszej bazy kodu i bardziej stabilnego oprogramowania.

Rozdzielenie obaw (SoC). Podziel swoją aplikację na odrębne funkcje, które w jak najmniejszym stopniu się pokrywają. (Microsoft).

„Problem” = „odrębna funkcja” = „odrębna sekcja”

„Concern” działa zarówno na wysokim, jak i niskim poziomie

Zasada pojedynczej odpowiedzialności  mówi, że każdy moduł lub klasa powinien odpowiadać za pojedynczą część funkcjonalności dostarczanej przez oprogramowanie, a odpowiedzialność ta powinna być całkowicie ujęta w klasie. Wszystkie jego usługi powinny być ściśle powiązane z tą odpowiedzialnością. (Definicja z Wikipedii)

„Odpowiedzialność” = „powód do zmiany” co zmienić? „Pojedyncza część funkcjonalności zapewnianej przez oprogramowanie” = jednostka podstawowa

Wniosek

• Zasada pojedynczej odpowiedzialności działa na podstawowych jednostkach -> działa na niskim poziomie

• Separacja problemów działa zarówno na wysokim, jak i niskim poziomie

• SRP i SoC współpracują ze sobą w celu oddzielenia problemów.
  Na niskim poziomie są dokładnie takie same

Ponieważ żadna z poprzednich odpowiedzi nie cytuje Roberta Martina, który stworzył Zasadę Pojedynczej Odpowiedzialności , myślę, że potrzebna jest tutaj bardziej miarodajna odpowiedź.

Inspirację Martina dla SRP czerpali David Parnas, Edsger Dijkstra (który ukuł termin Separacja obaw ) i Larry Constantine (który ukuł terminy Sprzężenie i spójność ). Martin skonsolidował swoje pomysły w SRP.

Innym sformułowaniem zasady pojedynczej odpowiedzialności jest:

Zbierz razem rzeczy, które zmieniają się z tych samych powodów. Oddziel te rzeczy, które zmieniają się z różnych powodów.

Jeśli się nad tym zastanowisz, zdasz sobie sprawę, że jest to kolejny sposób na zdefiniowanie spójności i sprzężenia. Chcemy zwiększyć spójność między rzeczami, które zmieniają się z tych samych powodów, i chcemy zmniejszyć sprzężenie między rzeczami, które zmieniają się z różnych powodów.

Jednak myśląc o tej zasadzie, pamiętaj, że powodem zmiany są ludzie . To ludzie żądają zmian. I nie chcesz zmylić tych ludzi ani siebie, mieszając razem kod, na którym zależy wielu różnych ludzi z różnych powodów.

Do pierwotnego pytania, różnica pomiędzy moll SRP i SoC jest to, że Martin rafinowany termin obawy w odniesieniu do ludzi .

Rozdzielenie obaw to proces; Zasada pojedynczej odpowiedzialności to filozofia projektowania / architektury. Nie są całkowicie rozłączne, ale służą różnym celom.

Podobnie, ale: SoC wiąże się z problemami: aby rozbić złożony problem na kilka problemów, SRP oznacza tylko jedną odpowiedzialność.

SRP i SOC działają na różnym poziomie abstrakcji. W obu przypadkach celem jest zmniejszenie sprzężenia i wzmocnienie spójności. Podczas gdy SRP działa bardziej na poziomie obiektu, SOC może również działać na poziomie implementacji funkcji. Funkcja może być implementowana przez jeden obiekt, ale także przez kilka obiektów. Dlatego sprzężenie i spójność obu zasad mogą się różnić.

Próbowałem dokonać porównania między Separacją obaw (SoC) a zasadą pojedynczej odpowiedzialności (SRP).

Różnice

• SRP jest na poziomie klasy, ale SoC jest w każdym programie komputerowym, abstrakcji ... lub czasami na poziomie architektonicznym.

• SRP dotyczy jakości (jak nie czego) podziału domeny na spójne klasy, które mają tylko jedną odpowiedzialność (jeden powód do zmiany). Z drugiej strony SoC to zasada projektowania polegająca na oddzieleniu kontekstu na odrębne sekcje, tak że każda sekcja dotyczy oddzielnego problemu (a nie jak), ponieważ istnieje wiele narzędzi (na przykład klasy, funkcje, moduły, pakiety,. ..), aby osiągnąć ten cel na różnych poziomach.

• Koncepcja SRP opiera się na spójności (wysoka kohezja), podczas gdy SoC jest zbliżona do Molecularity, divide and conquer (D&C), ... na każdym poziomie abstrakcji.

• SoC to dobra zasada projektowania, która radzi sobie ze złożonością, taką jak abstrakcja, podczas gdy aby dotrzeć do pojedynczych odpowiedzialnych klas, możesz użyć zasady SoC jako świetnego rozwiązania. Jako, że sposobem na poznanie, że klasa ma więcej niż jedną odpowiedzialność, jest wyodrębnienie innej odpowiedzialności (obawy) z tej klasy.

Podobieństwa

• Po zastosowaniu każdej z tych zasad kontekst staje się bardziej przydatny do ponownego wykorzystania, łatwiejszy w utrzymaniu, solidny, czytelny ....

Odpowiedź:

Separacja problemów (SoC) to termin bardziej wszechstronny - można go stosować na poziomie systemu lub na niższych poziomach, takich jak klasy (lub nawet metody w klasie)

Zasada pojedynczej odpowiedzialności (SRP) jest używana do omawiania SoC na niższych poziomach, np. W klasie

Sposoby o tym myśleć:

1. Na niskim poziomie SoC i SRP są synonimami. Można więc powiedzieć, że SRP jest terminem zbędnym - lub że SoC powinno być używane tylko do omawiania poziomu systemu

2. Biorąc pod uwagę (1), termin SoC jest nieco niejednoznaczny. Potrzebujesz kontekstu, aby wiedzieć, czy dyskusja dotyczy SoC wysokiego poziomu, czy niskiego poziomu SoC

3. Aby pamiętać, że SRP to termin odnoszący się tylko do niższych poziomów, pomyśl o tym: w języku potocznym „odpowiedzialność” jest zwykle dobrze zdefiniowaną rzeczą, którą można powiązać z określonym kodem, podczas gdy „obawy” są zwykle niejasne i mogą obejmuje kilka powiązanych rzeczy, dlatego być może SoC jest bardziej naturalnym rozwiązaniem do omawiania poziomu systemu niż SRP

4. SoC jest w pewnym sensie silniejszym wymaganiem / zasadą niż SRP, ponieważ ma zastosowanie na poziomie systemu i aby było naprawdę osiągnięte na poziomie systemu, musi być również stosowane przy opracowywaniu komponentów systemu. Oznacza to, że wysoki poziom SoC implikuje przyzwoity SoC / SRP na niższych poziomach - ale sytuacja odwrotna nie jest prawdą, to znaczy niższy poziom SoC / SRP nie oznacza SoC ani niczego w ogóle dla następnego wyższego poziomu, nieważne obejmujący system. Aby zobaczyć przykład SoC / SRP, który jest osiągany na poziomie metody, ale następnie naruszany na poziomie klasy, sprawdź ten wpis na blogu Artura Trosina .

Rozdzielenie problemów

Zasada Separation of Concerns (SOC) mówi, że artefakt kodu powinien umożliwiać skupienie uwagi na określonym aspekcie. Artefaktem kodu może być wszystko, od określonej funkcji po klasę lub cały pakiet, a nawet całą aplikację. Zasada SOC może być zastosowana na każdym poziomie architektonicznym w naszych aplikacjach. Przykładem architektury, w której zastosowano SOC, jest architektura warstwowa.

Zasada pojedynczej odpowiedzialności

Zasada pojedynczej odpowiedzialności (SRP) stanowi, że „moduł powinien mieć jeden i tylko jeden powód do zmiany” (Clean Architecture, Martin, s. 62). SRP dotyczy poziomu modułu i przy stosowaniu SRP należy skupić się na przyczynie zmiany.

Wniosek

Zasada SOC mówi, że artefakt kodu powinien umożliwiać skupienie uwagi na pewnym aspekcie. SRP konkretyzuje to, stwierdzając, że na poziomie modułu powinniśmy skupić naszą uwagę na przyczynie zmiany. Zatem SRP jest SOC.

PS Dla kompletności: wspólna zasada zamknięcia

Wspólna zasada zamknięcia (CCP) to przekształcenie SRP na jeszcze wyższym poziomie, na poziomie komponentu. CCP stwierdza, że ​​klasy, które zmieniają się z tych samych powodów i w tym samym czasie, powinny być zebrane w te same komponenty (Clean Architecture, s. 105). CCP to kolejny przykład SOC.