Projektowanie oparte na odpowiedzialności - Responsibility-driven design

Projektowanie oparte na odpowiedzialności to technika projektowania w programowaniu zorientowanym obiektowo , która poprawia hermetyzację dzięki zastosowaniu modelu klient-serwer . Koncentruje się na umowie , biorąc pod uwagę działania, za które obiekt jest odpowiedzialny, oraz informacje, które obiekt udostępnia. Zaproponowali ją Rebecca Wirfs-Brock i Brian Wilkerson.

Projektowanie oparte na odpowiedzialności jest w bezpośrednim kontraście z projektowaniem opartym na danych, które promuje definiowanie zachowania klasy wraz z przechowywanymi przez nią danymi. Projektowanie oparte na danych to nie to samo, co programowanie oparte na danych , które polega na używaniu danych do określania przepływu sterowania , a nie projektowaniu klas.

W modelu klient-serwer, do którego się odnoszą, zarówno klient, jak i serwer są klasami lub instancjami klas. W dowolnym momencie klient lub serwer reprezentuje obiekt. Obie strony zobowiązują się do zawarcia umowy i wymieniają się informacjami, przestrzegając jej. Klient może wysyłać tylko żądania określone w umowie, a serwer musi odpowiadać na te żądania. W związku z tym projektowanie oparte na odpowiedzialności stara się unikać zajmowania się szczegółami, takimi jak sposób realizacji wniosków, a zamiast tego określa jedynie zamiar określonego żądania. Korzyścią jest zwiększona hermetyzacja , ponieważ określenie dokładnego sposobu realizacji żądania jest prywatne dla serwera.

Aby jeszcze bardziej hermetyzować serwer, Wirfs-Brock i Wilkerson wzywają do funkcji językowych, które ograniczają zewnętrzny wpływ na zachowanie klasy. Żądają, aby widoczność elementów członkowskich i funkcji była drobnoziarnista, na przykład w języku programowania Eiffel . Jeszcze dokładniejsza kontrola widoczności parzystych klas jest dostępna w języku programowania Newspeak .

Przegląd

Projektowanie oparte na odpowiedzialności koncentruje się na obiektach jako behawioralnych abstrakcjach, które charakteryzują się ich obowiązkami. CRC-karta technika modelowania służy do generowania te abstrakcje behawioralne. Reszta struktury obiektu, w tym atrybuty danych, jest przypisywana później, w razie potrzeby. To sprawia, że ​​projekt jest zgodny z hierarchią typów dla dziedziczenia, co poprawia hermetyzację i ułatwia identyfikację klas abstrakcyjnych . Może również grupować zajęcia w oparciu o ich klientów, co jest uważane za wyjątkową umiejętność.

Dobry projekt zorientowany obiektowo obejmuje wczesne skupienie się na zachowaniach w celu zrealizowania możliwości spełniających określone wymagania oraz późne powiązanie szczegółów implementacji z wymaganiami. Takie podejście szczególnie pomaga w zdecentralizowaniu kontroli i dystrybucji zachowania systemu, co może pomóc w zarządzaniu złożonością dużych lub rozproszonych systemów o wysokiej funkcjonalności . Podobnie może pomóc w projektowaniu i utrzymywaniu narzędzi wyjaśniających dla modeli poznawczych , inteligentnych agentów i innych systemów opartych na wiedzy .

Cegiełki

W swojej książce Object Design: Roles, Responsibility and Collaborations , autorzy opisują następujące elementy składowe, które składają się na projekt oparty na odpowiedzialności.

  • Aplikacja: aplikacja jest określana jako zbiór obiektów wchodzących w interakcje.
  • Kandydaci: Kandydaci lub przedmioty kandydatów to kluczowe pojęcia w postaci obiektów opisanych na kartach CRC. Służą jako początkowe wynalazki w procesie projektowania obiektów.
  • Współpraca: współpracę definiuje się jako interakcję obiektów lub ról (lub obu).
  • Karty CRC: CRC oznacza kandydatów, obowiązki, współpracowników. Są to karty indeksowe używane we wczesnych projektach do rejestrowania kandydatów. Te karty są podzielone na stronę bez podszewki i linię.
    • Treść strony wyłożonej: Na tej stronie zapisywane jest nazwisko kandydata, jego obowiązki i współpracownicy.
    • Treść strony bez zaznaczenia: Na tej stronie zapisywane jest imię kandydata, jego cel w aplikacji, stereotypowe role i wszystko, co warto, np. Nazwy ról we wzorcach, w których uczestniczy.
  • Punkty aktywne: punkty aktywne to punkty aplikacji, w których występują różnice. Są one nagrywane przy użyciu kart Hot Spot.
  • Karty punktów aktywnych: Karty punktów aktywnych są używane do rejestrowania odmian z wystarczającą szczegółowością, aby można było rozróżnić istotną różnicę. Podobnie jak karty CRC, są one również tworzone z kart indeksowych . Te karty składają się z:
    • Nazwa hotspot
    • Ogólny opis zmiany
    • Co najmniej dwa konkretne przykłady, w których występuje zmiana

Obiekty

Obiekty są opisywane jako rzeczy, które zachowują się jak maszyny, które mogą być połączone razem, aby współpracować. Obiekty te odgrywają dobrze zdefiniowane role i zawierają odpowiedzi i informacje oparte na skryptach.

  • Otoczenie obiektu: inny termin określający podsystem. To logiczne zgrupowanie współpracowników.
  • Obowiązki: odpowiedzialność to obowiązek wykonania zadania lub znajomości informacji. Są one dalej klasyfikowane zgodnie ze scenariuszem ich użycia.
    • Obowiązki publiczne: Obowiązki publiczne to obowiązki, które obiekt oferuje innym jako usługi oraz informacje, które dostarcza innym.
    • Obowiązki prywatne: Odpowiedzialność prywatna to działania podejmowane przez obiekt w celu wsparcia obowiązków publicznych.
    • Podobowiązki: Czasami duża lub skomplikowana odpowiedzialność jest dzielona na mniejsze, zwane podobowiązkami. Są dalej kategoryzowane na podstawie tego, co robią.
      • Obowiązki podrzędne: obejmują główne etapy każdej odpowiedzialności podrzędnej.
      • Sekwencjonowanie obowiązków: Odnoszą się one do kolejności wykonywania obowiązków podrzędnych.

Role

Rola obiektu odnosi się do zewnętrznego spojrzenia na to, jakie usługi ogólne oferuje obiekt. Jest to zestaw powiązanych obowiązków. Może być zaimplementowany jako klasa lub interfejs. Interfejs jest jednak preferowaną implementacją, ponieważ zwiększa elastyczność, ukrywając konkretną klasę, która ostatecznie wykonuje pracę.

Stereotypy ról: Stereotypy ról to uproszczone role, które wiążą się z predefiniowanymi obowiązkami. Istnieje kilka kategorii.

  • Kontroler: Obiekt pełniący tę rolę podejmuje decyzje i ściśle kieruje działaniem innych obiektów.
  • Koordynator: ta rola reaguje na zdarzenia, delegując zadania innym.
  • Posiadacz informacji: Posiadacz informacji zna i dostarcza informacji.
    • Dostawca informacji: Niewielką odmianą posiadacza informacji jest dostawca informacji, który odgrywa bardziej aktywną rolę w zarządzaniu informacjami i ich utrzymywaniu. To rozróżnienie można zastosować, jeśli projektant potrzebuje bardziej szczegółowych informacji.
  • Interfacer: ta rola przekształca informacje i żądania między różnymi częściami aplikacji. Jest dalej podzielony na bardziej szczegółowe role.
    • Zewnętrzny interfejs: Zewnętrzny interfejs komunikuje się z innymi aplikacjami, a nie z własną. Jest używany głównie do hermetyzacji niezorientowanych obiektowo interfejsów API i nie współpracuje zbyt często.
    • Internal Interfacer: Zwany także interfacerem międzysystemowym. Działa jako pomost między otoczeniami obiektów.
    • Interfejs użytkownika: interfejs użytkownika komunikuje się z użytkownikami, odpowiadając na zdarzenia generowane w interfejsie użytkownika, a następnie przekazując je do bardziej odpowiednich obiektów.
  • Dostawca usług: ta rola wykonuje pracę i oferuje usługi komputerowe.
  • Strukturyzator: ta rola utrzymuje relacje między obiektami i informacjami o tych relacjach.

Styl sterowania

Ważną częścią procesu projektowania opartego na odpowiedzialności jest podział obowiązków związanych z kontrolą, który skutkuje opracowaniem stylu kontroli. Styl sterowania dotyczy przepływu sterowania między podsystemami .

  • Pojęcie kontroli: obowiązki i współpraca między klasami.
  • Centra sterowania: Ważnym aspektem rozwoju stylu sterowania jest wynalezienie tak zwanych centrów sterowania. Są to miejsca, w których przebywają obiekty odpowiedzialne za sterowanie i koordynację.
  • Odmiany stylów sterowania: Styl sterowania występuje w trzech różnych odmianach. Nie są to jednak precyzyjne definicje, ponieważ można powiedzieć, że jeden styl sterowania jest bardziej scentralizowany lub delegowany niż inny.

Scentralizowany styl sterowania

Ten styl sterowania narzuca proceduralny paradygmat na strukturę aplikacji i nakłada obowiązki związane z podejmowaniem głównych decyzji tylko na kilka obiektów lub na pojedynczy obiekt.

Rodzaje
  • Model wywołania zwrotnego: Sterowanie obiektami w aplikacji odbywa się w sposób hierarchiczny. Kontrola zaczyna się u podstawy i przesuwa się w dół. Jest używany w modelu sekwencyjnym.
  • Model menedżera: sterowanie obiektami w aplikacji odbywa się za pomocą tylko jednego obiektu. Generalnie jest implementowany w modelach współbieżnych. Można go również zaimplementować w modelu sekwencyjnym za pomocą instrukcji case .
Zalety
  • Logika aplikacji jest w jednym miejscu.
Niedogodności
  • Logika sterowania może stać się zbyt złożona
  • Administratorzy mogą stać się zależni od treści posiadaczy informacji
  • Obiekty mogą zostać połączone pośrednio poprzez działania ich kontrolera
  • Jedyna ciekawa praca jest wykonywana w kontrolerze
Kiedy użyć

Kiedy decyzje do podjęcia są nieliczne, proste i dotyczą jednego zadania.

Styl kontroli delegowanej

Styl sterowania delegowanego znajduje się pomiędzy stylem sterowania scentralizowanego i rozproszonego. Przekazuje część procesu decyzyjnego i większość działań obiektom otaczającym centrum sterowania. Każdy sąsiadujący obiekt ma do odegrania ważną rolę. Można go również nazwać modelem sterowanym zdarzeniami, w którym sterowanie jest delegowane do obiektu żądającego przetworzenia zdarzenia.

Typy [odniesienie]
  • Model transmisji: zdarzenie jest transmitowane do wszystkich obiektów w aplikacji. Kontrolę może przejąć obiekt, który może obsłużyć zdarzenie.
  • Model sterowany przerwaniami: będzie program obsługi przerwań, który przetworzy przerwanie i przekaże do jakiegoś obiektu, aby go przetworzyć.
Zalety
  • Łatwo to zrozumieć.
  • Chociaż istnieje zewnętrzny koordynator, obiekty mogą być mądrzejsze, aby wiedzieć, co mają robić, i mogą być ponownie wykorzystywane w innych aplikacjach.
  • Koordynatorzy delegujący zwykle wiedzą o mniejszej liczbie obiektów niż kontrolerzy dominujący.
  • Dialogi są na wyższym poziomie.
  • Zmiana jest łatwa, ponieważ zmiany zazwyczaj dotyczą mniejszej liczby obiektów.
  • Łatwiej jest podzielić prace projektowe między członków zespołu.
Niedogodności
  • Zbyt duży podział odpowiedzialności może prowadzić do słabych obiektów i słabej współpracy
Kiedy użyć

Gdy chce się oddelegować pracę do bardziej wyspecjalizowanych obiektów.

Styl sterowania klastrowego

Ten styl sterowania jest odmianą stylu scentralizowanego sterowania, w którym kontrola jest uwzględniana w grupie obiektów, których akcje są koordynowane. Główna różnica między stylem sterowania klastrowego i delegowanego polega na tym, że w stylu sterowania klastrowego obiekty decyzyjne znajdują się w centrum sterowania, podczas gdy w stylu sterowania delegowanego znajdują się głównie na zewnątrz.

Rozproszony styl sterowania

Rozproszony styl sterowania nie zawiera żadnych centrów sterowania. Logika jest rozproszona na całą populację obiektów, utrzymując każdy obiekt mały i budując między nimi jak najmniej zależności.

Zalety
  • Żaden
Niedogodności
  • Jeśli chcesz dowiedzieć się, jak coś działa, musisz prześledzić sekwencję żądań usług w wielu obiektach
  • Niezbyt nadaje się do wielokrotnego użytku, ponieważ żaden pojedynczy obiekt nie wnosi wiele
Kiedy użyć

Nigdy.

Preferowany styl sterowania

Po rozległych wynikach przeprowadzonych eksperymentów tylko kierownictwo wyższego szczebla ma umiejętności niezbędne do korzystania z delegowanego stylu sterowania i scentralizowanego stylu sterowania, który przynosi korzyści programistom. Nie ma kontekstu dotyczącego pracowników średniego szczebla.

Bibliografia

Bibliografia