0:00 / 0:00

Zasady SOLID na Backendzie: OCP - 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:02Mam dla Ciebie kilka wskazówek dotyczących wprowadzania w życie zasady open close.

0:08Wskazówka numer 1 Korzystaj z abstrakcji i polimorfizmu.

0:12Zasada Open Closed opiera się bardzo mocno na tym, żeby umiejętnie korzystać z

0:17abstrakcji i bardzo rozsądnie korzystać z polimorfizmu.

0:20Polimorfizm pozwala nam na łatwe wstrzykiwanie zależności.

0:25Będzie się to przewijało też w innych zasadach, gdzie będziemy pracować nad

0:29stworzeniem możliwie najbardziej elastycznego interfejsu konkretnego i

0:33elastycznego interfejsu, który z kolei pozwoli na łatwe podmiany klas w kodzie.

0:38Więc korzystaj z abstrakcji i polimorfizmu, żeby taki elastyczny kod

0:42tworzyć, wybieraj kompozycje zamiast dziedziczenia.

0:46Toczy się odwieczna batalia pomiędzy zwolennikami kompozycji i dziedziczenia.

0:50Przypomnę Ci tylko, że kompozycja polega na tym, aby komponować swój obiekt,

0:54komponować zachowanie obiektu na zasadzie wstrzykiwania nowych elementów lub innych

0:59obiektów wewnątrz tego pierwszego, a nie tworzenia łańcuchu dziedziczenia.

1:04W drzewie obiektów, gdzie będziemy mieć te same metody lub dziedziczone różne

1:08zachowania po klasie bazowej, więc kompozycja daje nam dużo większą

1:13elastyczność, bo w dziedziczeniu możemy odziedziczyć metody,

1:16których tak naprawdę nie potrzebujemy i tym samym będziemy łamać jeszcze kolejną,

1:20kolejną zasadę z cyklu solid a.

1:23W kompozycji możemy tworzyć dowolną liczbę obiektów w dowolnych

1:28konfiguracjach, które pozwalają z kolei wypełniać tę zasadę OCP Open Close, gdzie

1:33nasz kod nie jest modyfikowany, ale jest rozszerzany właśnie dzięki kompozycji, co

1:37widziałeś też w poprzednim przykładzie, gdzie pokazywałem konfigurację lub

1:40wstrzykiwanie zależności Millera.

1:43I wskazówka numer 3 projektuj zawsze pod kątem rozszerzania.

1:47Staraj się pisząc kod projektować go w taki sposób, aby naturalnie powstawały w

1:53nim miejsca, gdzie możesz wstrzykiwać zależności, jeśli tylko ten kod

1:58tych zależności będzie wymagał.

1:59Jeśli tylko ten kod będzie miał predyspozycje do tego, aby być

2:04rozszerzeniem, a jesteś w stanie to zidentyfikować na etapie planowania i

2:08designu architektury już wcześniej, to jesteś w stanie też projektować kod,

2:13projektować klasy i metody w taki sposób, aby możliwe było rozszerzanie.

2:18Może potrzeba jakiś service albo jakąś logikę wydzielić do osobnego obiektu

2:23i za chwilę powstanie nam kolejny wariant tej samej usługi, który będzie mógł być

2:27wstrzykiwać naprzemiennie do Twojej klasy usługi.

2:32Myśl o tym, żeby rozszerzać kod, nie modyfikować, ale rozszerzać tak, aby

2:36zasada open close principle mogła być zawsze spełniona.