0:00 / 0:00

Zasady SOLID na Backendzie: Rozwiązanie zadania teoretycznego ISP

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:00Zobacz teraz jak może wyglądać przykładowe rozwiązanie zadania teoretycznego, w

0:05którym chcemy zidentyfikować i zdefiniować kilka interfejsów w systemie zarządzania

0:09użytkownikami, nad którym pracujemy.

0:11W tych zadaniach teoretycznych i upewnić się, że żadna klasa nie jest

0:16zmuszona do implementacji interfejsu, którego nie używa.

0:20Przejdźmy więc do kodu.

0:22Zobacz ten główny skrypt.

0:23Mamy tutaj nowego użytkownika typu premium, ale już po samych portach

0:28widzisz, że pojawiły się nowe klasy, nowe obiekty.

0:32Przede wszystkim mamy klasę Registration Service i Registration Service.

0:37Odpowiada nam zarejestrowanie użytkownika i ten flow aplikacji wygląda tak, że mamy

0:41Registration Service, która implementuje tylko jedną publiczną metodę Register.

0:47Klasa Registration Service implementuje nam jeszcze interfejs Registration,

0:52który z kolei dalej definiuje nam tę jedną, jedyną metodę Register.

0:57Oznacza to, że ta klasa Registration Service implementuje dokładnie tylko tę

1:03jedną jedyną rzecz, której w danym kontekście potrzebujemy.

1:08Implementuje konkretny interfejs dla siebie zgodnie z zasadą ISP.

1:13Następnie mamy tutaj Auth Service, który odpowiada z kolei za autentykacji

1:19użytkownika, a Service implementuje interfejs API Authentication, który

1:24mamy tutaj w katalogu Identity.

1:26I mamy tutaj metodę Authentication, która przyjmuje username password i

1:31zwraca nam wartość typu Boolean.

1:34Jeśli użytkownik jest z autentykacji, zapisujemy go do bazy danych.

1:38Jeśli nie jest z autentykacji to go usuwamy, więc zobacz, że nasze

1:44repozytorium zyskało dodatkowe funkcje, dodatkowe metody, ale także

1:49pojawił się tutaj interfejs User Repository, który ma metodę Save delete,

1:54więc nasze repozytorium ma bardzo ściśle określony interfejs i korzysta dokładnie z

1:59tych metod, które są charakterystyczne dla repozytorium.

2:02Mamy tutaj jeszcze taki data transfer Object dla usera, który jest przekazywany

2:07z kolei jako podstawowa struktura danych, żeby zapisać ją do bazy danych.

2:12Natomiast w naszej klasie User w klasie bazowej pojawiła się dodatkowa metoda

2:18tutaj, którą dziedziczą wszystkie klasy pochodne.

2:21I ta metoda tutti transformuje strukturę tej klasy, transformuje jej

2:26pola do tego formatu do obiektu user.

2:30Wtedy mamy kasowanie obiektów i zwraca nam już nowy typ danych, mianowicie User Tito,

2:36który z kolei jest akceptowany jako parametr do zapisu.

2:42W naszym repozytorium mamy rozdzielone interfejsy, bardzo wąskie

2:46interfejsy i Registration Service i Auth Service.

2:49Mają bardzo wąski interfejs jeśli chodzi o metody publiczne.

2:53Mielibyśmy pewnie jakiś login service.

2:55Często jest tak, że pakujemy całą taką logikę autentykacji rejestracji

2:59użytkowników do jakiegoś auth serwisu klasy, która gdzieś w nazwie

3:03ma auth authentication.

3:04A tutaj pokazujecie jak można pójść dalej posługując się zasadą segregacji

3:10interfejsów, żeby te interfejsy były wąskie, bardzo wyspecjalizowane

3:14i bardzo konkretne.