Zasady SOLID na Backendzie: SRP - Wskazówki

0:02Przygotowałem dla Ciebie kilka wskazówek, które pomogą przy implementacji

0:07i spełnianiu wymogów zasady SRP.

0:09W Twoim kodzie wskazówka numer 1 Zidentyfikuj i Wydzial Operacje biznesowe.

0:15Jeśli piszemy kod, który ma mieć tylko jedną

0:18odpowiedzialność, to my musimy tę odpowiedzialność jasno określić.

0:23I w pierwszej kolejności takie określenie odbywa się przez identyfikację operacji

0:28biznesowych, procesów biznesowych, które zachodzą w aplikacji.

0:32Możliwe, że taki proces będzie się składał na więcej niż jedną operację i wtedy

0:37więcej niż jedna operacja będzie dobrym punktem wyjścia do wydzielenia tych

0:43pojedynczych odpowiedzialności.

0:45Analiza procesów biznesowych pomoże Ci także zidentyfikować aktorów w Twoim

0:50systemie aktorów, którzy będą korzystać z kodu.

0:53Wobec czego dużo łatwiej będzie stworzyć takie elementy kodu, takie metody, takie

0:58klasy, które faktycznie będą miały tę jedną odpowiedzialność według zasady SRP.

1:05Wskazówka nr 2 Skup się na elastyczności.

1:08Zasada SRP to nie jest tylko sztuka dla sztuki.

1:10To nie jest tylko trzymanie jednej konkretnej odpowiedzialności, jednego

1:14powodu do zmiany czy odpowiedzialności względem jednego aktora

1:17w klasie czy w metodzie.

1:18To przede wszystkim tworzenie elastycznego kodu.

1:22Dużo łatwiej modyfikuje się taki kod, który ogarnia i stosuje możliwie

1:26jak najmniejszy element logiczny.

1:28Dużo łatwiej pracuje się w trakcie faktoringu, dużo łatwiej usuwa się bugi,

1:33dużo łatwiej wreszcie usuwa się martwy kod, kiedy musimy usunąć po prostu

1:38klasę, która robi możliwie jak najmniej.

1:41Skup się na elastyczności, żeby ten kod mógł żyć, żeby mógł być elastyczny, mógł

1:45być łatwy do utrzymywania, łatwy w zmianie.

1:48No i wskazówka numer 3 Unikaj Gat Objects.

1:51Mówiłem wcześniej o gada Object Object dla przypomnienia to jest taka

1:55klasa, metoda, cokolwiek.

1:56Moduł, który robi wszystko robi zbyt wiele.

2:00Takim klasycznym obiektem często w systemach jest klasa user i klasa.

2:04User jest naszych systemach często odpowiedzialna za logowanie, zmianę hasła,

2:09zmiany w profilu, procesowanie płatności, zaproszenia użytkowników, wysyłanie

2:13maili i wiele, wiele innych.

2:15Unikaj takich obiektów.

2:16Po pierwsze trudno je testować, bo musisz brać pod uwagę bardzo wiele czynników, A

2:21jeśli dochodzą tam jeszcze jakieś prywatne metody, prywatne funkcje,

2:24no to masz pewność, że Twoje testowanie będzie naprawdę koszmarem.

2:28Więc unikaj ich. Twórz małe klasy.

2:30Nie bój się ilości klas.

2:32Nikt jeszcze nigdy nie widział zbyt dużej ilości klas w systemie, więc spokojnie

2:36możesz tworzyć małe klasy, małe metody, które faktycznie będą miały

2:40wąską odpowiedzialność.

2:41Niektóre języki programowania i niektóre narzędzia typu liter w tych językach

2:46programowania wręcz zaznaczają zbyt długie metody czy zbyt

2:50długie klasy jako błąd w formatowaniu i trzeba je refaktoryzacji, żeby

2:54spełnić wymagania literackie.

2:56Więc pomyśl o tym.

2:57Pamiętaj, żeby unikać gada obiektów.

2:59Wiadomo, w jakiś momentach iteracji taki grad object może powstawać, ale

3:04Twoim narzędziem jest faktoring.

3:05Zmienianie kodu, doprowadzenie do tej prostej formy, którą promuje zasada

3:09SRP jest jak najbardziej osiągalne.