Zasada segregacji interfejsów - Interface segregation principle

W dziedzinie inżynierii oprogramowania , zasada interface-segregacja ( ISP ) stwierdza, że klient nie powinien być zmuszony do zależeć od metody nie używa. Dostawca usług internetowych dzieli bardzo duże interfejsy na mniejsze i bardziej szczegółowe, dzięki czemu klienci będą musieli wiedzieć tylko o metodach, które ich interesują. Takie skurczone interfejsy są również nazywane interfejsami ról . ISP ma na celu utrzymanie systemu oddzielonego, a tym samym łatwiejszego refaktoryzacji, zmiany i ponownego wdrożenia. ISP jest jedną z pięciu zasad SOLID projektowania zorientowanego obiektowo, podobną do zasady wysokiej spójności GRASP .

Znaczenie w projektowaniu obiektowym

W ramach projektowania obiektowego , interfejsy dostarczają wielu abstrakcji kod uproszczenie i tworzą barierę zapobiegającą sprzężeniu zależności .

Według wielu ekspertów od oprogramowania, którzy podpisali Manifest Software Craftsmanship , pisanie dobrze przygotowanego i zrozumiałego oprogramowania jest prawie tak samo ważne jak pisanie działającego oprogramowania. Używanie interfejsów do dalszego opisywania intencji oprogramowania jest często dobrym pomysłem.

System może być tak sprzężony na wielu poziomach, że nie jest już możliwe dokonanie zmiany w jednym miejscu bez konieczności wielu dodatkowych zmian. Użycie interfejsu lub klasy abstrakcyjnej może zapobiec temu efektowi ubocznemu.

Początek

ISP został po raz pierwszy użyty i sformułowany przez Roberta C. Martina podczas konsultacji dla firmy Xerox . Firma Xerox stworzyła nowy system drukarki, który mógł wykonywać różne zadania, takie jak zszywanie i faksowanie. Oprogramowanie dla tego systemu zostało stworzone od podstaw. Wraz z rozwojem oprogramowania wprowadzanie modyfikacji stawało się coraz trudniejsze, tak że nawet najmniejsza zmiana zajmowała godzinny cykl ponownego wdrożenia, co czyniło rozwój prawie niemożliwym.

Problem projektowy polegał na tym, że prawie wszystkie zadania wykorzystywały jedną klasę Job. Za każdym razem, gdy trzeba było wykonać zadanie drukowania lub zszywania, nawiązywano połączenie z klasą Job. W rezultacie powstała klasa „gruba” z mnóstwem metod specyficznych dla różnych klientów. Dzięki temu projektowi zadanie zszywania zna wszystkie metody zadania drukowania, nawet jeśli nie ma z nich żadnego pożytku.

Rozwiązanie zaproponowane przez Martina wykorzystywało to, co dziś nazywa się Zasadą Segregacji Interfejsów. W przypadku oprogramowania Xerox dodano warstwę interfejsu między klasą Job a jej klientami za pomocą zasady Dependency Inversion Principle . Zamiast jednej dużej klasy Job stworzono interfejs Staple Job lub Print Job, który byłby używany odpowiednio przez klasy Staple lub Print, wywołując metody klasy Job. Dlatego dla każdego typu zadania stworzono jeden interfejs, który został zaimplementowany przez klasę Job.

Typowe naruszenie

Typowe naruszenie zasady Interface Segregation Principle podano w Agile Software Development: Principles, Patterns and Practices w „Przykładzie transakcji ATM” oraz w artykule napisanym również przez Roberta C. Martina, poświęconym ISP. W tym przykładzie omówiono interfejs użytkownika dla bankomatu, który obsługuje wszystkie żądania, takie jak żądanie wpłaty lub żądanie wypłaty, oraz sposób, w jaki ten interfejs należy podzielić na indywidualne i bardziej szczegółowe interfejsy.

Zobacz też

Bibliografia

Zewnętrzne linki

  • Zasady OOD – Opis i linki do szczegółowych artykułów na temat SOLID.