0:00 / 0:00

Zasady SOLID na Backendzie: ISP - Interface Segregation Principle

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:02Litera I, czyli zasada Integrated Security Nation Principle zasada

0:08segregacji interfejsów.

0:10Zasada ta mówi nam o tym, że żaden klient nie powinien zależeć od

0:14metody, której nie używa.

0:16Co za tym idzie, żadna klasa, która korzysta z innej klasy jako zależności,

0:22powinna mieć wgląd tylko w te metody, które są jej potrzebne.

0:27Tzn.

0:29Inaczej rzecz biorąc, kiedy zamawiamy na np.

0:31catering dietetyczny do domu, interesuje nas to, jakie mają menu, a nie interesuje

0:37nas jaka firma księgowa obsługuje ten nasz catering.

0:41I idąc jeszcze inaczej, tłumacząc to jeszcze w inny sposób, spełniając

0:46tę zasadę segregacji interfejsów.

0:49Musimy dążyć do takiej konfiguracji, w której mamy wiele różnych interfejsów

0:52specyficznych dla różnych klientów, po wiele interfejsów specyficznych dla

0:57klientów jest o wiele lepszym rozwiązaniem niż jeden główny interfejs

1:01ogólnego użytku lub taka klasa.

1:03Mówimy o tym często o takim wzorcu gat object anty wzorcu zresztą,

1:08w którym mamy klasę, która ma masę różnych metod, z których korzystają różni klienci,

1:12różne inne klasy i ta klasa robi dosłownie wszystko.

1:15Jedna zmiana w tej klasie pociąga za sobą konsekwencje wybuchu w

1:19innej części aplikacji i np.

1:22jeśli jedna klasa zależy od drugiej klasy, np.

1:26poprzez wstrzyknięcie, to powinna być powiązana jak najmniejszym interfejsem lub

1:30inaczej mówiąc powinna mieć wgląd tylko do tych metod i do tych pól, z których

1:35faktycznie będzie korzystać.

1:38I takie interfejsy i klasy, które są zależnościami, powinny zawierać

1:42też te metody, które są potrzebne.

1:44Powinny wiedzieć, w jakie miejsce zostaną rozstrzygnięte.

1:48Nie możemy budować abstrakcji na zaś na może kiedyś się przyda.

1:54Wobec tego klasa nie może zależeć od metod, których nie używa.

1:58Powtarzam to jeszcze raz, żeby mocno to wybrzmiało.

2:02Żeby interfejs komunikujący dwie klasy, dwie zależności był jak

2:06najbardziej specyficzny.

2:09Ta zasada może wydawać się skomplikowana, ale myślę, że przykład w kodzie

2:13wszystko rozjaśni, więc zapraszam już teraz do kolejnego materiału.