Zasady SOLID na Backendzie: DIP - Dependency Inversion Principle

0:02Ostatnia zasada The Dependency Invasion Principle,

0:06czyli zasada odwracania zależności.

0:08Ta zasada mówi nam o tym, że chcemy mieć elastyczny system,

0:14a najbardziej elastyczny system jest taki, kiedy zależności w tym systemie, w kodzie

0:19tego systemu odnoszą się wyłącznie do abstrakcji, a nie

0:22do konkretnych elementów, czyli odnoszą się do reguł, a nie odnoszą

0:26się do infrastruktury.

0:28I te zależności nie powinny się odnosić do modułów z konkretną implementacją.

0:33Więc jeśli mamy jakieś zależności, one powinny być możliwie jak

0:35najbardziej abstrakcyjne.

0:37I tutaj przychodzą nam z pomocą właśnie statycznie typowane języki z interfejsami.

0:41Mówimy cały czas o interfejsach.

0:43Zależnością powinien być interfejs, a nie konkretna implementacja.

0:47Jako moduły z konkretną implementacją będziemy rozumieć te moduły, w których

0:51zaimplementowane są już konkretne funkcje, czyli mamy zaimplementowane funkcje

0:56zdefiniowane w interfejsach.

0:58Uwaga Statyczne, statycznie typowane języki dynamiczne

1:02typowane języki mogą tutaj nie obrazować tego do

1:07końca tak, jak potrzeba.

1:11Posłużmy się cytatem Roberta Martina.

1:13W tworzonym systemie musimy natomiast unikać zależności od konkretnych, ale

1:17ulotnych elementów, czyli implementacja.

1:20Takimi elementami są moduły, nad którymi aktywnie pracujemy, a przez to poddawane

1:23są one częstym modyfikacjom, częstym modyfikacją.

1:27Czyli po prostu implementujemy jakiś kod i on żyje, on się zmienia.

1:30Natomiast interfejs kiedy definiujemy tylko interfejs.

1:33Typ interfejsu, Typ metody w interfejsie parametrów on będzie w miarę stabilny,

1:37bo logika zależy od implementacji.

1:40Definicja jest gdzie indziej, kontrakt jest gdzie indziej, więc będziemy mieć

1:43tutaj stabilną implementację i taką stabilną architekturę.

1:47Bo stabilna architektura jest architekturą, w której unika się

1:50zależności od ulotnych implementacji, czyli od konkretnych funkcji, od

1:54konkretów, a faworyzowane jest wykorzystywanie stabilnych,

1:58abstrakcyjnych interfejsów.

1:59Czyli często mówimy o tym np.

2:02w językach statycznie typowanych typu Java czyste Sharp.

2:05Tam bardzo duży nacisk kładzie się na definiowanie interfejsów.

2:10W skrypcie też będziemy mieć definiowanie interfejsów.

2:12W dynamicznie typowanych językach typu Python, Ruby to pojęcie.

2:16Ta zasada będzie bardziej rozmyta.

2:18Trzeba z większą subtelnością, z większą dokładnością skupiać się na

2:21definiowaniu interfejsów.

2:23Ten cognitive load niestety jest zdjęty z interpretera czy z kompilatora?

2:28Jak to jest w językach kompilowane na programistę?

2:32Niestety.

2:33A co to są te stabilne abstrakcje w ogóle?

2:35Bo stabilne abstrakcje to takie abstrakcje, które nie odnoszą się w żaden

2:38sposób do konkretnych, ulotnych klas.

2:40Definiują tylko kontrakt.

2:42Stabilne abstrakcje nie dziedziczą po konkretnych, ulotnych klasach.

2:45One są często abstrakcyjnymi klasami.

2:47To nie one wykorzystują, ale je się wykorzystuje do budowania konkretnej

2:52implementacji i nie pokrywają tych ulotnych funkcji.

2:55Ulotnych, czyli tych, które są już konkretną implementacją.

2:58Jak to wygląda w kodzie, zobaczysz w następnym materiale.