Różnica między zasadą jednolitej odpowiedzialności a rozdzieleniem obaw

Rozdział troski a zasada pojedynczej odpowiedzialności (SoC vs SRP)

Z linkowanego artykułu:

Separacja obaw (SoC) - jest procesem łamania programu komputerowego na odrębne funkcje, które nakładają się w funkcjonalności w jak najmniejszym stopniu. Problemem jest każdy element zainteresowania lub skupienia w programie. Zazwyczaj obawy są synonimem cech lub zachowania. http://en.wikipedia.org/wiki/Separation_of_concerns

Zasada jednolitej odpowiedzialności (SRP) - każdy przedmiot 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

Jedna odpowiedzialność stwierdza, że przedmiot jest odpowiedzialny za jedną jednostkę pracy.

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

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

Moim zdaniem zasada pojedynczej odpowiedzialności jest jednym z narzędzi / idiomów do osiągnięcia oddzielenia obaw.

Zasada jednej odpowiedzialności i oddzielenie trosk to naprawdę to samo.

Jasne, że możesz ugrzęznąć w akademickiej dyskusji próbując dokuczyć jakiejś różnicy między tymi dwoma, ale dlaczego? Pod każdym względem opisują to samo. Największym problemem jest to, że ludzie tak bardzo chcą wiedzieć, czym są "troska" i "odpowiedzialność", że być może brakuje im ważnej idei SRP i SoC.

Ten pomysł jest wystarczy podzielić bazę kodową na luźno powiązane odizolowane części. Pozwala to wielu programistom pracować nad różnymi częściami bez wpływu na siebie, a także pozwala pojedynczemu programiście modyfikować jedną izolowaną część bez łamania drugiej.

Jest to stosowane na poziomie modułu, np. MVC jest wzorcem architektonicznym promującym SRP i SoC. Baza kodowa jest podzielona na odizolowane modele, widoki i kontrolery. W ten sposób modyfikacja widoku może odbywać się niezależnie od modelu. Dwa dwa nie przeplatają się ze sobą.

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

Również na poziomie metody, podziel Duże metody na mniejsze.

W zasadzie. SRP jest zasadą, a nie regułą, więc nie musisz (Czytaj: nie możesz/nie powinieneś) podążać za nią religijnie do skrajności. To nie znaczy, że posuwamy się za daleko i mamy tylko jedną siódemkę. metoda liniowa w każdej klasie na przykład. Oznacza to po prostu ogólną zasadę dzielenia kodu na odizolowane części. Chodzi o to, że doprowadzi to do lepszej bazy kodowej i bardziej stabilnego oprogramowania.

Separacja trosk (SoC). Podziel aplikację na odrębne funkcje z jak najmniejszym nakładaniem się funkcjonalności. (Microsoft).

"troska" = "odrębna cecha" = "odrębna sekcja"

"troska" działa zarówno na wysokim, jak i niskim poziomie

Zasada jednej odpowiedzialności mówi, że każdy moduł lub klasa powinna mieć odpowiedzialność za pojedynczą część funkcjonalności zapewnianej przez oprogramowanie, a odpowiedzialność ta powinna być w całości ograniczona przez klasę. Wszystkie jej usługi powinny być ściśle dostosowane do tej odpowiedzialności. (Definicja Wikipedii)

"odpowiedzialność" = "powód do zmiany" zmienić co? "jedna część funkcjonalności dostarczone przez oprogramowanie " = jednostka podstawowa

Wniosek

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

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

• SRP i SoC współpracują w celu rozdzielenia obaw. Są
  dokładnie to samo na niskim poziomie

Rozdzielenie trosk jest procesem; zasada jednej odpowiedzialności jest filozofią projektowania / architektury. Nie są całkowicie rozdzielne, ale służą innym celom.

Podobne ale: SoC jest związane z obawami: aby rozbić złożony problem na kilka obaw, SRP ma mieć tylko jedną odpowiedzialność.

SRP i SOC pracują na różnym poziomie abstrakcji. Celem jest w obu przypadkach zmniejszenie sprzężenia i wzmocnienie spójności. Podczas gdy SRP działa bardziej na poziomie obiektu, SOC może również pracować nad implementacją poziomu funkcji. Funkcja może być zaimplementowana przez jeden obiekt, ale także przez kilka obiektów. W związku z tym sprzężenie i spójność obu zasad mogą się różnić.

Starałem się wyciągnąć porównanie między zasadą separacji trosk (SoC) i zasadą jednolitej odpowiedzialności (SRP).

Różnice

• SRP jest na poziomie klasy, ale SoC jest w każdym programie komputerowym, abstrakcja ... lub czasami poziom architektoniczny.

• SRP jest o jakości (jak nie co) dzielenie domeny na spójnych klas, które mają tylko jedną odpowiedzialność (jeden powód do zmiany). Z drugiej strony, SoC jest zasadą projektowania dla rozdzielenie kontekstu na odrębne sekcje, tak aby każda sekcja zajmowała się oddzielnym problemem (co nie jak), ponieważ istnieje wiele narzędzi (na przykład klasy, funkcje, Moduły, Pakiety, ...), aby osiągnąć ten cel różne poziomy.

• Koncepcja SRP opiera się na spójności (high cohesion), podczas gdy SoC jest bliskie Molekularności, dziel i rządź (D&C), ... na każdym poziomie abstrakcji.

• SoC jest dobrą zasadą projektowania, aby poradzić sobie ze złożonością, taką jak abstrakcja natomiast, aby dotrzeć do pojedynczych odpowiedzialnych klas, można użyć zasady SoC jako doskonałego rozwiązania. Jako, sposób, aby wiedzieć, że klasa ma więcej niż jedną odpowiedzialność jest, jeśli możesz wyodrębnić inną odpowiedzialność (troskę) z tej klasy.

Podobieństwa

• Po zastosowaniu każdej z tych zasad, Twój kontekst staje się bardziej wielokrotnego użytku, możliwy do utrzymania, solidny, czytelny, ... .