Tworzenie kodu według najlepszych praktyk
2 godz. 45 min · Full-stack i Programowanie
Rafał PiekaraSoftware KomandosNie 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.
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.
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.
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.
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.
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.
Solid to pewien zestaw zasad, wzorców, ale są też anty wzorce, bo jeśli mamy
jakieś zasady i wzorce, są one odpowiedzią lub próbą wyeliminowania
istniejących anty wzorców.
A dlaczego takie anty wzorce istnieją i jakie problemy z tym się wiążą?
Teraz opowiem Ci w tej lekcji więc jakie mamy problemy związane z
anty wzorcami dla zasady SRP?
takim kluczowym, najpopularniejszym anty wzorcem jest tzw.
cat object.
Co to jest ten gad Object Gad Object?
Jest to klasa, która robi zbyt wiele.
Ona będzie miała dużo publicznych metod, które robią zgoła różne rzeczy.
Jest to klasa trudna do testowania, bo musimy uwzględniać różne scenariusze.
Najgorzej jest, jeśli te wszystkie publiczne metody, które pozornie
odpowiadają za różne operacje biznesowe, korzystają z tych samych metod prywatnych.
Dochodzi tam dodatkowy narzut, dodatkowy cognitive load potrzebny do zrozumienia,
jak ten kod funkcjonuje i do tego, by go poprawnie przetestować.
W efekcie czego zmiana w jednym miejscu może wywoływać efekt lawiny, czyli
pociągać za sobą błędy lub zmiany zachowania w innych miejscach aplikacji
i w innych metodach danej klasy.
Cat Object anty wzorzec W zasadzie OCP można określić jako łatanie kodu.
O co tutaj chodzi?
Chodzi o to, że ciągle modyfikujemy istniejący kod, dodajemy nowe,
zagnieżdżone i złożone IF i w efekcie otrzymujemy np.
jedną metodę, która ma wiele zachowań i te zachowania dostosuje i różnicuje na
podstawie parametrów, które do niej przychodzą.
I tak naprawdę nasz kod przestaje być deterministyczny, staje się
nieprzewidywalny i trudny do utrzymania.
Trudny do czytania.
Pogwałcenie zasady SRP odbywa się we wzorcu polegającym na
naruszeniu kontraktu.
Jest to anty wzorzec polegający na nadpisywanie metod klasy bazowej,
które z kolei zmieniają zachowanie tej metody z klasy bazowej całkowicie.
Dostajemy znowu nieprzewidywalne zachowanie aplikacji,
trudne do testowania i niemożliwe praktycznie
do utrzymywania dla zasady ISP.
Takim anty wzorcem są pakowane interfejsy.
Chodzi o to, że mamy zbyt rozbudowane interfejsy implementowane przez klasy.
Jedna klasa dostaje zbyt dużo metod, musi implementować zbyt dużo metod, które
tak naprawdę jej są niepotrzebne.
Zaczynamy zależeć od niepotrzebnych metod i atrybutów, a klasy są po prostu
zmuszone do ich implementacji.
I wreszcie mamy zasadę DP, gdzie spotkasz się ze stosowaniem
bezpośrednich zależności.
Jest to anty wzorzec, który polega na tym, że nie definiujemy
odpowiednich abstrakcji.
Stosujemy właśnie te bezpośrednie zależności między klasami
wysokiego i niskiego poziomu.
Mamy trudne testowanie w izolacji, bo w ciele samej klasy dzieją się rzeczy,
których ciężko przewidzieć, do których często nie mamy dostępu, bo one
się dzieją w metodach prywatnych.
Jedna taka zmiana powoduje lawinowe zmiany w całym systemie.
Jakie są te problemy z anty wzorcami?
Przede wszystkim jest to trudny rozwój i utrzymanie.
Kiedy kod jest nie deterministyczny, ciężko go się rozwija i utrzymuje.
Pociąga to za sobą duże ryzyko błędów.
Jedna zmiana może wywołać efekt lawiny, efekt kuli śniegowej i pociągnąć za
sobą błędy w innych częściach systemu.
Co za tym idzie mamy problem z testowaniem, bo klasy
są nie deterministyczne.
Metody zmieniają swoje zachowanie na podstawie przekazanych parametrów
i kończymy ze słabą skalowalności, bo kod który jest trudny w utrzymaniu jest
też po prostu słabo skalowalny.
A w następnej lekcji pokażę Ci już przykłady na kodzie przykłady stosowania
tych anty wzorców, więc zapraszam Cię do kolejnego materiału.