Zasady SOLID na Backendzie: ISP - Przykłady kodu

0:02Przejdźmy teraz do praktycznego przykładu zasady segregacji interfejsów.

0:06Zobaczmy w kod.

0:08Mamy tutaj klasę Reports Controller, więc dalej jesteśmy w kontekście

0:12aplikacji webowej.

0:13Ta klasa ma jedną metodę publiczną jedną akcję Generate i ona

0:17generuje jakiś raport.

0:20Korzysta sobie z serwisu, który nazywa się Report Service

0:23i ten Report Service ma w sobie już tę metodę do generowania raportu.

0:27Jak wygląda klasa Report Service Report Service ma jedną metodę

0:31statyczną Generate Report.

0:34I w tej metodzie generuje się jakiś raport.

0:37Ona zwraca po prostu wygenerowany raport.

0:40Co jeśli będziemy potrzebować czegoś więcej?

0:44Oprócz wygenerowania raportu?

0:45Będziemy potrzebować jeszcze zapisać ten raport gdzieś na dysku,

0:49żeby go można było pobrać np.

0:51Albo żeby on po prostu był w jakimś archiwum.

0:53No to często można spotkać taki niechlujny kod, w którym będziemy mieć metodę, która

0:59będzie wykonywała te dwie czynności, bo chcemy spełniać zasady itd.

1:03Więc mamy generowanie raportu i zapisywanie.

1:06I teraz co tutaj dostajemy?

1:08Dostajemy jakiegoś pdf a na podstawie tego PDFa generujemy ten raport

1:13i go zapisujemy na dysku gdzieś lokalnie.

1:17I mamy taką brzydką metodę, brzydką klasę, która gdzieś tam

1:20tworzy sobie wygenerowany raport.

1:22Jeśli chcemy, żeby ten raport był w formacie

1:25PDF, to nam wygeneruje go w formacie PDF, potem go zapisze gdzieś lokalnie.

1:31Jeśli mamy go zapisanego i mamy ten PDF, to wtedy nam zwróci pdf, a jeśli

1:37to ma być PDF to wrzuci wygenerowany raport.

1:39Masa logiki.

1:40Na pierwszy rzut oka widać, że to jest proszenie się o problemy

1:44i będziemy próbowali to teraz rozwiązać.

1:47Rozwiązaniem może być tutaj rozdzielenie interfejsów.

1:52Tutaj zobacz, że mamy zbudowane jeden interfejs, jeden

1:56interfejs dla każdej z tej akcji.

1:59Dla każdej akcji akcji generowanie raportu akcji, zapisywanie akcji podglądu, bo

2:02zapisujemy ten raport na dysku, żeby umożliwić podgląd później np.

2:07w przeglądarce.

2:08I co tu się dzieje?

2:09Mamy metodę Generate i w tej metodzie generate generujemy raport.

2:13Ale w jaki sposób?

2:15Ano przekazujemy mu parametry.

2:17Zaczynamy sterować zachowaniem tej metody Generate and save report za pomocą

2:21parametrów, więc jeśli chcemy wygenerować raport to robimy

2:25mu pdf false, czyli nie rób PDFa i nie zapisuj go, bo sam chcemy tylko

2:28wygenerować bo chcemy coś z tym zrobić później w metodzie save.

2:33Już się domyślasz pewnie co będzie, bo będzie przekazania innych parametrów.

2:37Tutaj musimy wygenerować pdfa, bo go chcemy zapisać, więc

2:40generujemy pdfa i go zapisujemy.

2:43Czyli mamy save thru pdf i mamy metodę preview,

2:47gdzie z kolei potrzebujemy tylko zrobić PDF, ale go nie zapisujemy.

2:52Wrzucamy tego pdfa, więc mamy bardzo złożony interfejs, bo ta

2:56metoda generate and save report ona robi bardzo dużo rzeczy

3:00I jak widzisz mamy metodę, która zapisuje raport i ona musi wiedzieć o tym,

3:05że on musi być zapisany w PDF.

3:06Ja mam metodę, która robi tylko podgląd PDF a, ale ona

3:11wie też, że tam się da zapisać.

3:13Wie za dużo, korzysta ze zbyt dużej ilości funkcji po gwałcona.

3:19Zasada segregacji interfejsów. Jaka jest droga?

3:23Drogą do rozwiązania tego problemu jest uproszczenie

3:27interfejsu, więc możemy sobie tę klasę Report Services podzielić.

3:31Tą dużą metodę podzielić na mniejsze.

3:34Możemy zrobić osobną metodę do generowania raportu, osobną metodę do generowania

3:39raportów w formacie PDF i osobną metodę do zapisywania raportów w formacie PDF.

3:45Więc mamy trzy różne metody.

3:47Dążymy do takiej konfiguracji, w której będziemy mieć specyficzny, mały interfejs.

3:53I co tutaj mamy teraz w klasie Reports Controller?

3:56Otóż metoda Generate korzysta tylko z tej jednej metody Generate Report.

4:00Metoda Save będzie miała tylko Save PDF report i metoda Preview będzie miała tylko

4:05Generate PDF Report i dostarczenie go jako Preview.

4:10Teraz chciałbym się zatrzymać nad jedną rzeczą, mianowicie nad wzorcem

4:14projektowym, który się nazywa Builder, który bardzo ładnie nam pomoże

4:18korzystać z minimalnego interfejsu w zależności od tego, jaki klient

4:23będzie korzystał z obiektu.

4:24Więc nie będziemy do końca musieli definiować jakiegoś master obiektu, który

4:29ma wszystkie te warunki w sobie zawarte.

4:32Definiować nieskończone ilości metod, o której muszą wiedzieć nasi klienci.

4:37Możemy sprawić, że za pomocą wzorca Builder będziemy mieć poszczególne

4:42elementy naszego procesu.

4:45Na tyle elastyczny, że każda klasa, która będzie korzystała z tego jako zależności,

4:49będzie mogła sobie je dowolnie konfigurować, dowolnie układać.

4:53I zobacz jak wygląda nasz reports Builder.

4:55Wykorzystanie w praktyce tego wzorca Builder.

4:58Mamy metodę Generate Report, która tutaj generuje sam raport i we wzorcu Builder

5:03ważne jest to, że on za każdym razem zwraca swoją własną instancję, tak, że na

5:08tej zwróconej instancji zwróconej wartości możemy wywoływać kolejne metody instancji.

5:13Więc mamy tu zwróconą instancja Report Buildera.

5:16Potem mamy Generate PDF Report i tutaj możemy na podstawie tej instancji

5:20Buildera sobie coś wygenerować.

5:21Możemy PDF a i potem możemy go zapisać lokalnie.

5:25Jak wykorzystanie takiego wzorca może ułatwić nam tworzenie kodu?

5:29Ano widzimy to w klasie Reports Controller, gdzie metoda Generate robi

5:32sobie nowy builder, generuje raport i zwraca ten raport do klienta.

5:38Z kolei później metoda Preview buduje sobie buildera, generuje

5:43raport, generuje PDFa i zwraca PDFa.

5:46A metoda Save zrobi wszystkie te rzeczy, czyli wygeneruje raport, wygeneruje PDFa

5:51i zapisze go na dysku.

5:53Więc mamy minimalny interfejs.

5:55Każda z tych akcji z granulek tRNA, a razem połączone mogą dopiero budować

6:01wielki proces biznesowy.

6:03Wiadomo, możemy iść dalej te metody rozbić na poszczególne klasy takich serwisów jak

6:07Generate Report, PDF, Preview, Report, Save, PDF, Report.

6:10I potem w tych klasach NK postulować sobie logikę, którą wcześniej mieliśmy

6:14zawartą w metodach Buildera.

6:16To jest kolejny sposób, żeby Zenka przechować to sobie

6:19całą logikę, której tutaj używamy w poszczególnych klasach, formie

6:22takich service object czy komentów.

6:25Rozwiązań jest sporo.

6:26Zasada segregacji interfejsów jest dobrą zasadą, która pozwala

6:32tworzyć elastyczny kod, tak jak to pokazałem w przypadku wzorca Builder,

6:35gdzie mogliśmy bardzo elastycznie sobie tutaj sterować tym w jaki sposób

6:40dany raport będzie wygenerowany.

6:41Interfejsy są małe, interfejsy są wygodne, to też jest łatwo testowane.

6:46Nic tylko używać.