Zasady SOLID na Backendzie: Wprowadzenie do zasad SOLID

0:02Żeby dobrze zrozumieć, jak stosować zasadę solid na back endzie,

0:06przejdziemy teraz szybkie wprowadzenie do samych zasad i omówimy to, czego dotyczą.

0:12Więc samo słowo solid może się kojarzyć z angielskim słowem solidny

0:15i nie bez powodu tak jest.

0:18Zasady SOLID zasady kryjące się za tymi pięcioma literami sprawiają, że poprawne

0:24ich zastosowanie pozwoli na tworzenie solidnego oprogramowania.

0:29Jak to się dzieje? Zaraz się o tym dowiesz.

0:32Więc zasady SOLID mówią nam o tym, w jaki sposób powinniśmy rozmieszczać kod.

0:37Kod, który jest pogrupowane przez funkcje w klasy, w moduły, w struktury.

0:42Jak rozmieścić ten kod i struktury danych w klasach, w obiektach,

0:48w modułach, w naszym kodzie, w aplikacji?

0:50Jak rozmieścić?

0:51Można skrócić to, że zasady SOLID to są pewne wytyczne dotyczące porządkowania

0:57kodu tak żeby wszystko było na swoim miejscu i było łatwe do

1:01znalezienia i do podmiany.

1:04Mówią nam o tym, w jaki sposób mają być powiązane klasy, w jaki sposób mają się ze

1:09sobą komunikować, aby nie było silnych wiązań między tymi

1:13klasami, aby kod był elastyczny, szybki w zmianie, łatwy w modyfikacji

1:20i odporny na błędy.

1:22Klasa w tym rozumieniu, w którym będziemy ją tutaj omawiać to pewna metoda

1:27grupowania funkcji i danych w programowaniu w kodzie.

1:31Więc o takich klasach będziemy dzisiaj rozmawiać.

1:34Będzie to w dużej mierze oparte na programowaniu obiektowym, bo zasady SOLID

1:39to są dobre praktyki, które są wykorzystywane właśnie w

1:42programowaniu obiektowym.

1:44I po co w ogóle będziemy stosować te zasady SOLID?

1:47Zasady stolic stosujemy, aby nasze oprogramowanie dobrze znosiło zmiany,

1:53to znaczy dobrze znosiło zmiany.

1:55Zmiana powinna być łatwa, szybka do wdrożenia i stabilna, tzn.

1:59jeśli zmieniamy jedną część systemu, to zmienia się dosłownie jedna część systemu,

2:04a cały system jest w dużej mierze cały czas stabilny i nic się z nim nie dzieje.

2:09Moja zmiana nie powinna powodować żadnych błędów w innych częściach systemu.

2:14Nasze oprogramowanie powinno być łatwe do zrozumienia.

2:17Zasady SOLID to pewien zbiór dobrych praktyk uznanych przez

2:23społeczność, rozumianych tak samo przez programistów, niezależnie od języka

2:27programowania, niezależnie od frameworka i niezależnie od kultury, języka,

2:33komunikacji i pochodzenia.

2:35To jest pewien zbiór uniwersalnych zasad.

2:37I nie bez powodu odwołałem się na początku do Dekalogu, do dziesięciu przykazań,

2:42które tak samo są rozumiane w każdej kulturze, tak samo będzie

2:45rozumiane hasło nie zabijaj.

2:48W każdej kulturze, bo dotyczy ono jednej konkretnej rzeczy, jest bardzo jasno

2:52sprecyzowane i jasno starają się być sprecyzowane też zasady SOLID w

2:57programowaniu i implementacja tych zasad SOLID jest

3:01podstawą gry używanych komponentów.

3:03W kodzie gry używane komponenty to takie komponenty, takie części kodu, zbiory

3:08klas, które pozwalają nam na budowanie systemu na zasadzie klocków LEGO, że

3:15możemy wziąć jeden komponent, przepiąć go w inne miejsce lub do innego systemu,

3:21skopiować ten sam komponent i system będzie się zachowywał

3:24stabilnie i przewidywalnie.

3:26No i omówmy sobie krótko, bardzo krótko czego dotyczą te zasady?

3:30Zasada numer jeden SRP Single Responsibility Principle,

3:34czyli zasada pojedynczej odpowiedzialności według definicji mówi nam, że każdy moduł

3:40powinien mieć jeden i tylko jeden powód do zmian Lub inaczej.

3:45Każdy moduł, każda klasa, każda metoda powinny odpowiadać względem

3:49tylko jednego aktora.

3:51Lub jeszcze mówiąc prościej.

3:52Każdy moduł, każda klasa, każda metoda powinny robić tylko jedną rzecz.

3:59Jeśli coś robi tylko jedną rzecz, wtedy jesteśmy pewni, że nasz

4:04system może być stabilny.

4:06Jeśli idziemy do piekarza, kupujemy u niego bułkę, a nie oczekujemy,

4:10że będzie miał jeszcze żarówki.

4:12I o tym będzie nam mówiła zasada SRP.

4:16Druga zasada to jest OCP Open Closed Principle po polsku zasada otwarte

4:22zamknięte mówi nam o tym, że zmiana zachowania powinna zachodzić przez dodanie

4:26nowego kodu, a nie modyfikację istniejącego lub według definicji,

4:30o której mówi Robert Martin.

4:32Nasze oprogramowanie powinno być otwarte na rozszerzenie, a zamknięte

4:39na modyfikacje.

4:40Powinniśmy go łatwo rozszerzać bez konieczności modyfikowania

4:45wstecz istniejącego kodu.

4:47O tym mówi nam zasada otwarte zamknięte.

4:50Zasada numer trzy LSB blisko substytuty Principle Zasada podstawy Barbary List

4:57Lisko to bardzo chwytliwa zasada, która definiuje nam

5:02zasadę konstruowania wspólnych kontaktów między komponentami, między klasami

5:07takich kontraktów, których wspólny kontrakt pozwala na zastępowanie

5:11jednych elementów drugimi.

5:13Będziemy mieć jeden wspólny kontrakt spełniane przez kilka elementów

5:17i co pozwoli nam wymieniać te elementy w jednej konstrukcji na dokładnie takiej

5:23samej zasadzie jak działają klocki Lego, gdzie mamy klocki o różnych kształtach,

5:28ale sposób ich budowy, wypustki w klocki lego, dziurki

5:33w ich strukturze sprawiają, że dowolne klocki możemy między sobą przypinać.

5:38I to właśnie jest zobrazowanie tej zasady. ESP.

5:44Kolejna zasada ESP.

5:45ISP Interface Segregator Principle.

5:48Zasada segregacji interfejsów będzie nam mówiła o tym, żeby unikać tworzenia takich

5:54zależności, które będą powiązane z niepotrzebnymi elementami.

5:58Będzie ona mówiła o tym, żeby nie zależeć od elementów, które są niepotrzebne.

6:03Żeby nie budować zbyt rozbudowanych interfejsów.

6:06Żeby nasze interfejsy klas w kodzie były możliwie jak najbardziej

6:11wyspecjalizowane i o tym nam mówi zasada ISP.

6:14I ostatnia z zasad Deep Dependency in Version Principle

6:18zasada odwrócenia zależności.

6:22Zasada uwielbiana przez programistów mówi nam o tym, że reguły biznesowe nie powinny

6:28zależeć od szczegółów technicznych.

6:29Powinny być wyizolowane i to szczegóły techniczne mogą być wstrzykiwać

6:35do naszych reguł biznesowych dowolnie.

6:38Dlatego mówiłem na początku, że zasady SOLID nie zależą od bazy danych i od

6:43frameworka, bo niezależnie jaką bazę danych użyjemy, te zasady powinny mieć

6:48dokładnie takie samo działanie i powodować dokładnie takie samo

6:51zachowanie w naszym kodzie.

6:52A na straży właśnie tego zachowania będzie stała ta zasada DIP.

6:57O szczegółach będziemy mówić w kolejnych lekcjach.