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.
Pora teraz posegregować parę interfejsów.
Zasada segregacji interfejsów będzie miała odzwierciedlenie w faktoringu
tego przykładu, gdzie jak widzisz mamy jeden interfejs, który jest zbyt duży dla
tej logiki, którą tutaj mamy i klasa zajmująca się zarządzaniem użytkownikami
niepotrzebnie musi implementować metodę do zarządzania siecią i tak samo klasa
zarządzająca siecią niepotrzebnie musi zarządzać użytkownikami.
Więc rozdzielimy ten jeden gruby interfejs na dwa osobne.
Ja tutaj zrobię nowy moduł, który nazwę Network Manager.
OK, mamy ten nowy moduł wydzielony i tak samo tutaj wydzielamy i podmieniamy
nazwę tego modułu na Customer Manager.
Co teraz musimy zrobić?
Ano musimy odpowiednie moduły zainstalować, czyli tak
naprawdę odpowiednie interfejsy zaimplementować w poszczególnych klasach.
Więc Customer Service będzie miał Customer Managera.
I w tym momencie nie potrzebujemy już metody zarządzania siecią.
No i Network Manager będzie miał to, co jest związane z zarządzaniem siecią
i nie musi się martwić już o klientów. Proste.
Faktoring.
Oczywiście kod jest mniej, jest bardziej czytelny.
Mamy wąskie interfejsy.
Nasze klasy zależą tylko od tego, czego muszą.
Logika mocno Zenka.
Postulowana zasada SRP także spełniona, więc czego chcieć więcej?
Możemy przechodzić do klasy o testach na zasadzie i ASP, segregacji interfejsów.