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.
Zasada open close otwarte zamknięte i przykład, który będę Ci
pokazywał do znudzenia.
Ale przykład z kodu, który często spotykamy w aplikacjach produkcyjnych.
Mamy klasę, która generuje nam faktury w zależności od tego, jaki rodzaj
faktury podamy w parametrach.
Chcemy tę klasę z refaktoryzacji, żeby spełniała zasadę otwarte zamknięte, więc
proponuję na początek wydzielić sobie osobne klasy właściwe dla
poszczególnych rodzajów faktur.
Wiesz to już z lekcji teoretycznych, więc zaczynamy od klasy Standard Canvas,
która będzie miała metodę Generate.
I tutaj będzie jakaś logika generowania faktury.
Przenieśmy sobie ten print, który tutaj mamy.
Możemy sobie customers dać jako parametr do tej metody, żeby uprościć.
I utwórzmy sobie drugą klasę, która będzie Detail Canvas i ona
tutaj też będzie miała.
Metodę Generate, bo implementuje ten sam interfejs i generujemy sobie tutaj
tę fakturę dla naszego klienta.
Wobec czego w tym momencie nie będziemy potrzebować ani rzucania wyjątku,
ani tutaj przekazywania Invest Type.
Bo tak naprawdę zamiast End Voice Type możemy w tym momencie
przekazać sobie sam In Voice.
I tutaj wywołać po prostu info jeszcze na raty.
A jakby wyglądało wywołanie tej klasy gdzieś indziej?
A no zobaczmy.
W ten sposób możemy mieć jakiegoś customer, którym będzie np.
John. I teraz tworzymy sobie nowy generator.
To jest invalid generator.
I teraz tworzymy nową fakturę Standard Voice, inną fakturę Detail Voice
i możemy sobie wygenerować poszczególne faktury za pomocą naszego generatora.
I teraz, gdybyśmy chcieli dodać sobie nowy rodzaj faktury, np.
Company in Voices, tworzymy nową klasę, która generuje nam to fakturę według
określonej logiki i nasz kod generatora Info Generator nie wymaga
żadnych modyfikacji.
Rozszerzamy kod poprzez dodawanie nowych elementów, ale nie
modyfikujemy już istniejącego.
Jak to wpływa na testowanie pokażę Ci w kolejnym materiale.