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.
Zanim pokażę Ci testy dla zasady ESP, omówię krótko zmiany, które
wprowadziłem przed testowaniem.
Mianowicie wydzieliłem nasze menedżera i nasze dwie klasy do osobnych plików, a w
pliku xls przeniosłem te moduły, które będziemy budować w poszczególnych klasach.
Dla czytelności i lepszej organizacji kodu.
Teraz przejdźmy do testów.
Klasa testu Customer Service Manager sprawdza, czy implementuje prawidłowy
interfejs i sprawdzamy, czy odpowiada względem konkretnej metody.
To jest taki prosty test, który sprawdza poprawność implementacji zasady ESP i
odpowiedniego interfejsu.
Ten test jest dodatkowe.
Dodałem go na potrzeby przykładu, żeby wyjaśnić tylko, że możemy także sprawdzić,
czy nasza klasa nie implementuje niepotrzebnych metod.
W tym przypadku jest to Manage Network.
Analogiczny test mamy w Network Operations Manager.
Sprawdzamy moduł, sprawdzamy czy ma odpowiednie metody, sprawdzamy, czy nie
ma tych metod, których nie potrzebuje. Test jest prosty.
Dalszymi krokami może być już testowanie logiki, która niczym się nie różni
od normalnych testów jednostkowych.
Chciałem Ci pokazać tę konwencję, którą możesz zastosować, by
sprawdzić, czy Twoje klasy implementują konkretny interfejs i już na
bazie testów jednostkowych dowiedzieć się, że struktura Twojego kodu odpowiada
poszczególnym zasadom SOLID.
W tym przypadku zasadzie segregacji interfejsów.