0:00 / 0:00

Zasady SOLID na Backendzie: SRP - Refactoring

Tworzenie kodu według najlepszych praktyk

2 godz. 45 min · Full-stack i Programowanie

Rafał PiekaraSoftware Komandos

Czego się nauczysz

Teoretyczne wyjaśnienie każdej z 5 zasad SOLID
Przykłady zastosowania SOLID w kodzie Ruby i Typescript
Zadania teoretyczne polegające na zaprojektowaniu kodu zgodnie z SOLID
Praktyka i refaktoring kodu legacy w kierunku zasad SOLID
Przykłady testowania kodu implementującego zasady SOLID

Teoretyczne podstawy

Nie zrozumiesz SOLIDa bez teoretycznych podstaw. Przejdziemy przez założenia stojące za każdą z nich. Przeanalizujemy problemy, które możesz spotkać oraz dowiesz się dlaczego ciągle jeszcze tak wielu programistów nie stosuje się do tych zasad.

Przykłady zastosowania SOLID w kodzie Ruby i Typescript

Ruby i Typescript to technologie, które świetnie odzwierciedlają uniwersalizm SOLIDa. Te złote zasady działają w językach dynamicznie typowanych i interpretowanych jak Ruby oraz przy statycznym typowaniu na przykładzie Typescript.

Projektowanie kodu zgodnie z SOLID

Zanim zabierzesz się za programowanie warto poćwiczyć SOLIDny sposób myślenia. Zmierzysz się z zadaniami, w ramach których będziesz projektować kod tak, aby wszystkie zasady SOLID znalazły w nim swoje zastosowanie.

Praktyka i refaktoring w kierunku SOLID

Prawda jest taka, że kod, z którym w większości pracujemy ma swoją historię. Czasami historia ta jest tak bolesna, że klasy i metody są zagmatwane, poplątane i trudne w utrzymaniu. Gdy dotrzesz do tego miejsca będziesz mieć w arsenale wszystkie potrzebne narzędzia, żeby zmierzyć się z zadaniami praktycznymi, które przekształcą kod legacy w SOLIDne arcydzieło.

Testy, testy, testy

Tak ważny temat, jak testowanie nie może zostać pominięty. Między innymi po to też stosujemy zasady SOLID, żeby nasz kod praktycznie sam się testował. Napiszesz więc testy, których wzorce możesz wykorzystać w dowolnym projekcie, dowolnej technologii, jeśli tylko kod, który testujesz będzie spełniał wymagania zasad SOLID.

Dla kogo jest ten kurs?

Nie ma znaczenia, czy dopiero zaczynasz przygodę z programowaniem, czy też jesteś starym wyjadaczem, który klasami i interfejsami myśli przy zagryzaniu tosta na śniadanie. Ten kurs jest właśnie dla Ciebie. Technologia ani język programowania też nie mają znaczenia. Zasady SOLID to uniwersalny zbiór. Ich znajomość sprawi, że Twój kod będzie lepszy, łatwiejszy w utrzymaniu i odporny na perturbacje i zmiany.

0:00Przygotowałem teraz dla Ciebie praktyczny przykład, który razem z refaktoryzacji

0:04mamy tutaj Telekom serwis, gdzie mamy cztery metody odpowiedzialne

0:09za poszczególne czynności.

0:11Już na pierwszy rzut oka widać, że każda z tych metod wykonuje różne zadania

0:17i odpowiada względem różnych aktorów.

0:20Wobec tego przystąpimy teraz do szybkiego faktoringu i wydzielenia

0:26poszczególnych warstw.

0:27W tej klasie możemy zacząć od tej metody add payment i stwórzmy sobie tutaj jakiś

0:32payment serwis, który będzie miał tą metodę.

0:36Add payment przyjmuje jako parametr payment

0:41do jakiejś wewnętrznej tablicy payments będzie sobie dodawał ten nowy payment.

0:46Tutaj w konstruktorze ustalimy jeszcze wartość początkową dla Payment.

0:51I gotowe.

0:52Możemy teraz podmienić wywołanie tego serwisu w metodzie Add payment.

0:58Zrobimy sobie Payment Service New adult Payment Payment.

1:04OK, więc pozbyliśmy się tutaj logiki z klasy Telecom Service i

1:09wydawaliśmy ją do zewnętrznej klasy Payments Service.

1:13Oczywiście Telekom Service w tym momencie będzie pełnił rolę takiego Orchestra Tora,

1:18który będzie wywoływał poszczególne serwisy w zależności od potrzeby.

1:22Więc nie potrzebujemy teraz tej zmiennej instancji Payments.

1:26Zajmijmy się teraz planami.

1:29Utwórzmy sobie teraz klasę Plan Service.

1:35I utwórzmy metodę Change Plan, która przyjmuje parametr New Plan.

1:43Klasa + Service wymaga jeszcze konstruktora i wartości początkowej dla.

1:50Pierwotnego planu, więc ustalmy sobie tutaj plan.

1:57Podmieniamy plan i w metodzie Change Plan podmieniamy istniejący plan na plan, który

2:03wymieniamy, wobec czego możemy tutaj wywołać.

2:09Plan Serwis ustawić wartość początkową jako serwis plan i zmienić na nowy plan

2:15naszego plan serwisu.

2:16Kolejna delegacja została wykonana.

2:19Przejdźmy do kolejnej klasy i kolejną klasą będzie klasa odpowiedzialna

2:22za fakturowanie refaktoryzacji.

2:24Cały telekom serwis do serwisów do serwis Objects.

2:28Żeby było prościej wydzielając to odpowiedzialności, Oczywiście możemy tutaj

2:31się w bardziej zaawansowane wzorce architektoniczne.

2:35Natomiast zależy nam, żeby ten telekom, serwis i wszystkie poszczególne mniejsze

2:40granulaty klasy spełniały zasadę SRP.

2:43Więc przejdźmy do Invest Serwisu.

2:46Stwórzmy sobie inny serwis, który będzie miał metodę Generate Invisible.

2:56I ten device serwis powinien przyjmować jakiś parametr np.

3:01customers i on będzie nam generował fakturę dla danego klienta.

3:07I tutaj podmieniamy wywołanie Token Voice Service i metoda Generate Inbox.

3:12Na koniec zostaje nam Twój Customer i stworzymy sobie tutaj np.

3:16klasę Modified i będzie miał metodę Native Customer.

3:21Przyjmuje parametr Customer i.

3:26Podmieniamy wywołanie tej klasy, więc w tym momencie wycięliśmy logikę z

3:31tego rejestratora Telekom Service to poszczególnych klas, które teraz mają

3:35tylko jedną odpowiedzialność, a orkiestra Tor nie ma w sobie żadnej logiki.

3:39Wszystkie operacje biznesowe deleguje do serwisów, które za nie odpowiadają.

3:45I w następnej lekcji zobaczysz jak wielki ma to wpływ na jakość i wygodę testowania

3:49tego kodu, więc zapraszam Cię do kolejnego materiału.