Zasady SOLID na Backendzie: DIP - Przykłady kodu

0:02Teraz pora na praktyczny przykład z Dependency Injection Principle.

0:06Przejdźmy do kodu.

0:07Kod w Ruby mamy trzy klasy Employee Admin Support Officer, więc mamy uwaga, uwaga!

0:11Co mamy 3 aktorów w kodzie.

0:14Mamy pracownika, mamy administratora i jakiegoś pracownika supportu.

0:18I każda z tych klas pewnie będzie jakoś wykorzystywana w naszym systemie.

0:23W jaki sposób będzie wykorzystywana i co decyduje o tym, która klasa powinna

0:27być wykorzystywana w danym scenariuszu?

0:29O tym będzie decydowała nasza fabryka. Wzorzec Factory.

0:33Mamy fabrykę, która na podstawie jakichś tam argumentów będzie nam budować

0:37konkretną klasę tego aktora.

0:40Tutaj właśnie w tej metodzie build mamy też jakiś serwis, który też ma jakieś tam

0:44argumenty i on sobie tego aktora buduje właśnie z User Factory.

0:48Bierze sobie to fabrykę, przekazuje mu jakieś argumenty i mówi daj mi tutaj

0:52aktora i fabryka już mu zwraca aktora, który ma uwaga będzie

0:55miał wspólny interfejs.

0:56Więc zasada else cały czas tutaj się trzymamy wszystkich zasad.

1:01No i mamy serwis, który służy do potwierdzania płatności.

1:06Ten serwis będzie nam potwierdzał płatność w metodzie

1:10publicznej CALL, ale jeśli płatność zakończy się

1:14powodzeniem, to nam wyśle powiadomienia.

1:16Czyli jesteśmy w tym trybie powiadomień.

1:18I tu mamy dobrze nam znanego email native era, który z kolei przyjmuje parametr

1:22user, czyli pewnie naszego aktora i temu aktorowi wysyła powiadomienie.

1:26Sama klasa Configure Payment Service nie ma pojęcia komu wysyła powiadomienie.

1:31On nie wie czy wysyła go support oficerowi czy employee, czy czy adminowi.

1:35To jest dla niej nieistotne.

1:37Następnie zobacz, że tutaj w klasie config payment nie mamy już wykorzystania

1:43factory, nie mamy wykorzystania fabryki, mamy usera jako parametr i mamy

1:47notyfikację type jako parametr, czyli mamy kilka typów powiadomień.

1:52I co tu się dzieje?

1:53Mamy analogicznie to samo wysłanie powiadomienia, natomiast już będzie to

1:58wszystko opakowane w metodę send notyfikacje.

2:01I tutaj sens notyfikacji on wygląda w ten sposób Mamy info log, tu jest switch.

2:06Ale nieważne.

2:07Mamy tutaj ideologię, bo w zależności od tego jakie mamy notyfikacje type takiego

2:11note ofiara możemy musimy tutaj użyć i możemy użyć E-mail od

2:16frajera, slack net i frajera.

2:17Albo wysłać sms a do tego usera.

2:20No i rodzi się tutaj pewien problem, który możemy rozwiązać przez

2:24wstrzyknięcie zależności.

2:26Bo w tym momencie tutaj, w tym poprzednim przykładzie zbyt mocno interesujemy się

2:31tym, w jaki sposób ma być wysłane powiadomienie, a tak naprawdę

2:35klasa, która odpowiada za potwierdzenie płatności nie powinna się interesować

2:41abstrakcją, konkretną implementacją.

2:44Wysłanie powiadomienia nie interesuje potwierdzania płatności.

2:47Wie jakie powiadomienie wysyła.

2:49On ma wysłać powiadomienie. A jakie?

2:51Tym powinna się zająć już abstrakcja.

2:53To abstrakcją będzie wprowadzony teraz notice layer i ten notice layer będzie

2:58wykorzystany w metodzie Send notyfikacje i w momencie potwierdzenia

3:02płatności tutaj dostajemy frajera.

3:05Czyli nie musimy mieć notyfikacje typu nie musimy if ować.

3:09Jaki to jest typ notyfikacji, ale będziemy mieć gotowego, zbudowanego frajera.

3:14Gotową abstrakcję będziemy mieć zwróconą.

3:16I ta abstrakcja po prostu wywołuje metodę call i wysyła konkretnemu usera

3:22powiadomienie.

3:23Interfejs jest prosty, a zależność jest odwrócona.

3:26Nie zależymy już od implementacji, ale zależymy od abstrakcji, od tego

3:30frajera, jaki zostanie wysłany.

3:32A tutaj będziemy sobie budować konkretnego frajera lub przekazywać

3:36konkretne wartości.

3:38Więc jeśli user jest supportem to wysyłamy email notice, a jeśli admin to slack

3:42notice layer I to jest bardzo proste.

3:44Na wyższym szczeblu, na wyższym szczeblu abstrakcji możemy sobie

3:47pozwolić na taką flagę.

3:49Możemy skorzystać z factory, z metody wytwórczej, z czegokolwiek co zbuduje nam

3:53odpowiedni obiekt, więc tutaj odwracamy zależność.

3:57Sam serwis, który potwierdza zamówienie nie zależy już od implementacji.

4:01Nie mamy zależności od tego, jakie powiadomienie zostanie wysłane,

4:05bo to wszystko jest gdzieś wyżej.

4:07My tylko dostajemy serwis, usługę, która powiadamia i ona

4:11wysyła już konkretne powiadomienie.

4:13Ta logika jest zamknięta.

4:15W tej usłudze mamy spełnione i odwrócone zależności i co więcej w testach później

4:21możemy sobie stworzyć takiego fake not i frajera, żeby nie wysyłać prawdziwych

4:26powiadomień sms owych jak odpalamy testy, żeby nie spamować naszych użytkowników.

4:31Taki fejk i frajer może w tej metodzie po prostu nic nie robić albo wstrzykuje

4:36żeby sprawdzić implementację, przetestować nasz kod.

4:39Proste odwrócenie zależności wzorzec, który jest uwielbiany.

4:42Zasada, która jest uwielbiana przez programistów wszelakich

4:45technologii poznają. Warto ją poznać.

4:48Będziemy jeszcze ćwiczyć praktycznie to odwracanie zależności, więc

4:52zapraszam Cię dalej.