Wróć do strony głównej
Angular

Angular & Interface Segregation Principle

Wstęp

To już czwarty artykuł w serii dotyczącej skrótu SOLID. Jest to zbiór zasad, dzięki którym możemy pisać kod, który łatwiej będzie nam skalować, oraz zmieniać zachowanie naszej aplikacji, bez ruszania kodu dużej części aplikacji.

 

Na zbiór zasad składają się:

 

Dzisiaj zajmiemy się Interface Segregation Principle 🙂

Interface Segregation Principle

Credit: https://blog.larapulse.com/clean-code/solid-in-simple-words

 

Tak jak widać na obrazku – klienci nie powinni być zmuszani do polegania na interfejsach, których nie używają. Innymi słowy lepiej więcej mniejszych interfejsów, niż jeden duży.

 

Co to oznacza w praktyce?

 

Spójrzmy na przykład. Załóżmy, że w naszej aplikacji mamy następujący widok:

Jest to tabela z listą użytkowników. Pokazuje ona nazwę, oraz status danego użytkownika. Model został zaimplementowany w poniższy sposób:

Nasza aplikacja działa tak, że po podwójnym kliknięciu w wiersz przechodzi do widoku szczegółów:

Pokazujemy tutaj zdecydowanie więcej informacji, niż te, które są na widoku listy. Dlatego moglibyśmy model dostosować tak, aby ten sam był używany dla widoku listy, jak i widoku szczegółów (korzystając z opcjonalnych pól):

Takie podejście rodzi jednak kilka problemów. Po pierwsze, model dla widoku listy zawiera pola, które tam fizycznie nie występują. Po drugie, mając opcjonalne pola w wielu miejscach w aplikacji, bardzo szybko może się okazać, że nie wiemy gdzie dane pole jest zawsze wymagane, a gdzie nie. Po trzecie, w przypadku refaktoru (np. zmiany odpowiedzi z serwera), nie będziemy wiedzieć, które pola możemy zmienić/usunąć, a które nie.

 

Dlatego lepiej jest stworzyć oddzielny model dla widoku listy, i dla widoku szczegółów. Wtedy unikniemy opcjonalnych pól, a nasze komponenty będą miały jasno zdefiniowane zakresy wiedzy o modelach, jakie obsługują.

I dla widoku szczegółów:

W ten sposób trzymamy się zasady Interface Segregation Principle.

 

Spójrzmy na inny przykład. Załóżmy że mamy aplikację do obsługi maili i użytkowników. Składa się ona z 2 głównych widoków. Pierwszy to widok administratora, gdzie możemy:

  • usuwać,
  • dodawać,
  • aktualizować użytkowników.

Jest to panel widoczny tylko dla niewielkiej liczby użytkowników. Drugi widok to widok z filtrem wiadomości. W tym miejscu możemy tylko pobrać listę użytkowników lub szczegóły danego użytkownika. Widok ten jest używany przez większość użytkowników aplikacji. Oba widoki korzystają z serwisu do pobierania danych z serwera:

Widać więc, że panel filtrów wiadomości korzysta tylko z 2 metod – „getAll” i „getOne”. Pozostałe są mu zbędne. Idąc za definicją “lepiej mieć więcej interfejsów, ale mniejszych”, powinniśmy tutaj wydzielić podinterfejsy. Jeden, zawierający metody dostępne dla większości użytkowników:

Oraz drugi, z akcjami wymagającymi odpowiednich uprawnień:

Potem zamiast używać konkretnej implementacji w obu widokach, powinniśmy wstrzyknąć utworzone interfejsy:

W ten sposób komponenty mają dostęp tylko do tych metod, z których rzeczywiście korzystają. Dzięki temu reguła Interface Segregation Principle jest zachowana.

W następnym artykule zajmiemy się już ostatnią regułą składającą się na SOLID – Dependency Inversion Principle 🙂

O autorze

Wojciech Janaszek

Jestem Angular i NestJS developerem. Swoją przygodę zaczynałem od pierwszych wersji "nowego" Angulara (2 wzwyż). Od niedawna korzystam również z NestJS (którego nauka znając dobrze Angulara przychodzi łatwo - wszystko jest bardzo podobne). W swojej pracy dużą uwagę przykładam do tzw. clean code i clean architecture. Lubię mieć “porządek” w kodzie :) W wolnym czasie interesuję się sportowymi samochodami, ogólnie pojętym motorsportem. Gram również amatorsko w siatkówkę.

Chcesz razem z nami tworzyć treści na bloga? Dołącz do nas i twórz wartościowe treści dla sympatyków Angulara z Angular.love!

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *