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.
W tej lekcji przekaże Cię kilka wskazówek dotyczących implementowania zasady
Interfejs Segregator on Principle.
Wskazówka numer jeden wyjdzie, ale konkretne interfejsy.
Skoro musimy segregować jakoś te interfejsy, no to potrzebujemy wydzielić i
zdefiniować je bardzo, bardzo konkretnie.
Więc wydzielić konkretne interfejsy, takie, które będą miały
wąski zakres wąskich scope.
Muszą to być interfejsy, które nie będą zmuszały nas do implementowania lub do
wykorzystywania metod niepotrzebnych.
Wobec czego korzystaj też z tych pryncypiów, z tych wskazówek, które
przekazałem Ci odnośnie zasady SRP pojedynczej odpowiedzialności.
Bo to jest dobry punkt wyjścia do tego, żeby wydzielić konkretne interfejsy.
Wskazówka nr 2 Unikaj przerośniętych interfejsów.
Jeśli tworzysz konkretne interfejsy, to automatycznie unikasz
przerośniętych interfejsów.
Ale jeśli zobaczysz jakiś przerośnięty interfejs, klasę, która zawiera zbyt wiele
metod, warto Warto pomyśleć o faktoringu i takiej drobnej regule skauta, w której za
każdym razem, kiedy dotykasz jakiegoś kodu, zostawiasz go
lepszym niż go zostałeś.
Zostałaś więc unikaj przerośniętych interfejsów, takich interfejsów, które
implementują albo nakazują nam implementować.
Zbyt duży kontrakt, zbyt dużo niepotrzebnych metod.
No i wskazówka numer 3 wyjdźcie!
Zależności klienckie z naszego kodu korzystają klienci.
Klientem naszego kodu może być nawet inna klasa.
Warto sprawdzić, jakie zależności klienckie będą potrzebne do obsługi
tych zapytań, do obsługi kontaktu z innymi klientami, z innymi klasami, do
wywoływania metod wydzieli zależności, sprawdza, jakie to
są zależności i opakować je w interfejsy.
Wtedy będziemy mieć dużo małych interfejsów, które z kolei
będą funkcjonować jako przydatne wtyczki w naszym kodzie.
A kod będzie elastyczny, łatwy w zmianie, łatwy w wykorzystaniu, no i przede
wszystkim stabilny i bezpieczny.