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.
I pora na testy dla naszego refaktoryzacji tego kodu.
Zobacz, że w katalogu lib pojawiły się osobne pliki dla poszczególnych rodzajów
faktur, tak samo jak klasa, interfejs, generator.
I one tutaj mają po prostu tę logikę, którą wcześniej w
Extra chowaliśmy do osobnych obiektów.
Teraz zobaczmy jak wyglądają testy.
Klasa Detail in Voice ma prosty test, który sprawdza generowanie faktury.
Tutaj wiadomo w zależności od tego, jaka jest logika generowania faktury, możemy
sobie sprawdzać więcej elementów.
Podobnie klasa Standard End Voice sprawdza dokładnie ten sam sposób działania logiki.
No i mamy info generator i co robi separator?
On sobie sprawdza czy klasa Invest Generator wywołuje konkretną metodę na
przekazanym parametrze canvas na przekazanej fakturze.
Co tu się dzieje?
My w ogóle nie musimy polegać na tym, jakie mamy typy faktur
zdefiniowane w systemie.
Możemy sobie stworzyć taki testowy obiekt fake check in voice, który będzie
zaimplementował tę metodę, na której nam zależy.
Żeby ją wywołać w klasie generatora przekazujemy ją jako parametr i
wykonujemy tylko operacje na tej takiej zaślepki, na tej klasie
stworzonej tylko na potrzeby testów.
Ale zobacz, że dostaliśmy tak naprawdę nowy rodzaj faktury, który mógłby zostać
umieszczony gdzieś tutaj w katalogu lib i tak samo podlegał by
tej logice, która została stworzona w generate invalid w
metodzie generate in voice.
Jak widzisz dodajemy nowy typ faktury i nie zmieniamy żadnego kodu.
Klasa generatora zawsze będzie działać tak samo, bo te wszystkie obiekty
typu invalid, które przekazujemy implementują ten sam interfejs.
To znaczy, że mają tę samą metodę publiczną, którą możemy
wywołać w klasie generatora.
Testowanie z Open Close Principle jest naprawdę piękne.