0:00 / 0:00

Zasady SOLID na Backendzie: Przykłady śmierdzącego kodu

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:00W poprzednim materiale mówiłem o problemach związanych ze stosowaniem

0:04anty wzorców przeciw zasadom SOLID.

0:07A teraz pokażę Ci przykład takiego śmierdzącego kodu.

0:11Przejdźmy do anty wzorca zastosowanego w zasadzie SRP.

0:15Kod, który Ci pokazuję napisany jest w języku Ruby.

0:19Zobacz, że mamy tutaj klasę User Manager, która ma trzy główne publiczne metody,

0:23które mają totalnie różne zachowanie.

0:25W pierwszej kolejności mamy jakąś walidację, mamy tworzenie użytkownika i

0:29wysyłanie maila, kod object trzy metody, które robią totalnie inne operacje.

0:35Teraz zasada OCP w zasadzie OCP.

0:38Jak już mówiłem w jednej z poprzednich lekcji, takim symptomem pogwałcenia tej

0:43zasady OCP jest info loga I widzisz, że mamy klasę Generate Report

0:48i mamy typy takich raportów przekazywane jako parametr jest if jest if.

0:53If type pdf Generujemy jakiś pdf if type html generujemy jakiś HTML.

0:59Tu będzie pewnie jakaś logika odpowiedzialna za

1:01wygenerowanie tego raportu.

1:03Gdybyśmy dodali kolejny typ, musielibyśmy dodać kolejnego IFA zamiast tak jak to w

1:07zasadzie powinno się robić wstrzyknąć zależność poprzez tworzenie jakiegoś

1:11nowego obiektu lub posłużenia się wzorcem Factory.

1:16Przejdźmy do zasady LSB. Co tutaj mamy?

1:19Mamy tutaj brak możliwości podstawiania klas.

1:23Mamy klasę bazową Node i FIR, która powinna mieć metodę Not HiFi.

1:27i tutaj mamy email native layer, który wyśle nam maila.

1:30Ale mamy też SMS Native, który oprócz wysłania SMS a będzie aktualizował

1:34użytkownika jakimiś danymi, więc zmienia całkowicie to główne zachowanie

1:40tej metody z klasy bazowej.

1:41Bo jak sama nazwa metody wskazuje powinno się wysłać jakieś powiadomienie, a nie

1:46powinno dojść do żadnych operacji na bazie danych.

1:50Teraz zasada ISP i śmierdzący kod związany z interfejsami.

1:55Mamy duży interfejs implementowany przez klasę Auth Service.

1:59Metody, które totalnie nie współgrają z odpowiednią logiką.

2:03Mamy Auth serwis, który odpowiada za logowanie, rejestrację, wysyłanie

2:07zaproszeń, wysyłanie maili powitalnych.

2:09A docelowo chcielibyśmy skończyć z czymś takim jak tutaj poniżej.

2:13W tym przykładzie, gdzie mamy osobne klasy do logowania, do rejestracji, do wysyłania

2:18powiadomień czy do wysyłania maili powitalnych Mamy rozdzielone interfejsy, a

2:24tutaj mamy pogwałcenie tej zasady zbyt gruby świat, interfejs.

2:30No i na koniec zasada DP, gdzie mamy klasę User report, która

2:36nie bazuje na żadnych zależnościach. Wszystko tu się dzieje.

2:39Mamy jakiś MongoDB adapter, który jest tworzony bezpośrednio w metodzie

2:44odpowiedzialnej za generowanie raportu.

2:46Tworzone jest połączenie do bazy danych, poszukiwanie usera.

2:49Tutaj jest rozłączone połączenie z bazą danych, zwracane są

2:53jakieś dane użytkownika.

2:55Dzieje się tutaj za dużo.

2:56Nie ma zależności, nie wiemy.

2:58Z wierzchu testując tę klasę nie wiemy co tak naprawdę się tam dzieje.

3:02Są dźwigania obiekty.

3:03Zależymy bardzo od bazy danych.

3:05Nasz kod nie jest elastyczny i nie jest skalowalny.

3:08Tutaj pokazałem Ci takie przykłady śmierdzącego kodu, który nie widział

3:13nigdy zastosowania zasad SOLID.