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 numer 2 Zasada OTP Open Closed Principle, czyli zasada otwarte
zamknięte zasada otwarte zamknięte mówi nam o tym, że jakiś element oprogramowania
powinien być otwarty na rozbudowę, czyli na rozszerzanie, ale zamknięty na
modyfikacje, czyli dodawanie nowego kodu nowej funkcjonalności powinno się odbywać
przez dodawanie nowego bloczka do budowli, a nie przebudowanie tych
istniejących bloczków.
Jeśli musimy przebudowywać istniejące bloczki, to znaczy, że gdzieś popełniony
został błąd w projekcie tego oprogramowania.
I wujek Martin mówi tutaj bardzo doniosłą rzecz, która mi się niezmiernie podoba.
Mówi Jeśli prosta rozbudowa wymagań systemu powoduje ogromne zmiany w
oprogramowaniu, to architekci tego systemu ponieśli spektakularną porażkę.
Żeby nie ponieść spektakularnej porażki, trzeba pamiętać właśnie o zasadzie open
closed, która przychodzi do nas z pewnymi wspierającymi
technikami, bo sama zasada open close principle jest dość mocno abstrakcyjna.
Natomiast wypracowaliśmy sobie przez lata już pewne wzorce i praktyki, które
pomagają ją zastosować w praktyce.
Jedną z takich praktyk może być dziedziczenie.
Innym może być kompozycja, w której będziemy komponować klasy.
Czyli mamy te dwa teamy kompozycja versus dziedziczenie.
Możemy wstrzykiwać zależności, stosować wzorzec Dependency injection,
możemy stosować wzorzec wstrzykiwania zależności.
Możemy stosować też inne wzorce projektowania, które znamy, czyli np.
dekorator lub strategie.
A jak stosuje się zasadę open close principle w kodzie?
To zobaczysz w następnej lekcji.