0:00 / 0:00

Zasady SOLID na Backendzie: LSP - Wskazówki

Tworzenie kodu według najlepszych praktyk

2 godz. 45 min · Full-stack i Programowanie

Rafał PiekaraSoftware Komandos

Czego się nauczysz

Teoretyczne wyjaśnienie każdej z 5 zasad SOLID
Przykłady zastosowania SOLID w kodzie Ruby i Typescript
Zadania teoretyczne polegające na zaprojektowaniu kodu zgodnie z SOLID
Praktyka i refaktoring kodu legacy w kierunku zasad SOLID
Przykłady testowania kodu implementującego zasady SOLID

Teoretyczne podstawy

Nie 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.

Przykłady zastosowania SOLID w kodzie Ruby i Typescript

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.

Projektowanie kodu zgodnie z SOLID

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.

Praktyka i refaktoring w kierunku SOLID

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.

Testy, testy, testy

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.

Dla kogo jest ten kurs?

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.

0:02No i porada wskazówki do zasady pani Barbary blisko.

0:05Wskazówka numer 1.

0:07Projektuj pod kątem wspólnego interfejsu.

0:09Podmiana łatwa.

0:11Podmiana nie jest możliwa, jeśli nie będziemy mieć wspólnego interfejsu.

0:16Wobec czego jeśli Twój kod powinien obsługiwać kilka wariantów tego samego

0:22zachowania, to projektuj tak, aby klasy odpowiedzialne za poszczególne

0:28zachowanie, bo na pewno masz osobne klasy, bo spełniasz zasadę SRP, aby klasy

0:33odpowiedzialne za poszczególne zachowania miały wspólny interfejs, tak jak to było

0:37pokazane na przykładach w poprzednim materiale.

0:40Więc projektowanie pod kątem wspólnego interfejsu umożliwi Ci

0:44wstrzykiwanie i łatwe podmiany.

0:46Wskazówka numer 2 Unikaj nadpisywania metod, zmieniając ich zachowanie

0:51w momencie, kiedy będziesz się posiłkować dziedziczeniem

0:54i dziedziczyć po jakiejś klasie bazowej, możliwe jest, że będziesz

0:58musiał musiała nadpisać metody.

1:01Unikaj tego, żeby je nadpisać w taki sposób, aby totalnie

1:04zmieniały swoje zachowanie.

1:06Uzasadnionym jest implementowanie metod tego samego interfejsu w różny sposób.

1:11Natomiast w momencie dziedziczenia dziedziczymy pewną logikę po klasie

1:16bazowej, po tej klasie, po której dziedziczą Twoje kolejne obiekty.

1:19W tym momencie, kiedy napiszemy metodę, zmieniając radykalnie jej zachowanie,

1:24nasz system przestaje być stabilny.

1:26Bo kolejny developer, który wejdzie do tego systemu będzie chciał użyć tej

1:29klasy, wywołać tą napisaną metodę.

1:31Może się nieźle zdziwić, kiedy jej zachowanie będzie totalnie inne i system

1:34nie będzie zachowywał się tak jak tego oczekujemy, a więc nie będzie

1:38przewidywalny i nie będzie stabilny.

1:41No i wskazówka numer 3 pilnuj spójności kontaktów.

1:44Kiedy spełniamy zasadę else i mamy te spójne interfejsy, te interfejsy muszą

1:50mieć też spójny kontrakt, a więc lista parametrów i zwracanych

1:53wartości musi być spójna.

1:55Więc pilnuj spójności kontraktów.

1:57Implementując elastyczne interfejsy i tworząc obiekty,

2:01które są przygotowane do podstawienia, muszą mieć stabilny kontrakt, najlepiej

2:06typowany, najlepiej dobrze zrealizowany kontrakt komunikacji

2:10między sobą a klasami.

2:11Które z nich będą korzystać?