Dane, kontekst i interakcja

Dane, kontekst i interakcja ( DCI ) to paradygmat używany w oprogramowaniu komputerowym do programowania systemów komunikujących się obiektów . Jego cele to:

Aby poprawić czytelność kodu zorientowanego obiektowo, nadając zachowaniu systemu status pierwszej klasy;
robi system ) od powoli zmieniającej się wiedzy o domenie (czym jest system ), zamiast łączyć oba w interfejsie jednej klasy;
Aby pomóc twórcom oprogramowania wnioskować o stanie i zachowaniu na poziomie systemu, a nie tylko o stanie i zachowaniu obiektu;
Wspierać obiektowy styl myślenia, który jest zbliżony do mentalnych modeli programistów, a nie klasowy styl myślenia, który przyćmił myślenie obiektowe we wczesnej historii obiektowych języków programowania.

Paradygmat oddziela model domeny (dane) od przypadków użycia (kontekst) i ról odgrywanych przez obiekty (interakcja). DCI jest uzupełnieniem modelu-view-controller (MVC). MVC jako język wzorców jest nadal używany do oddzielania danych i ich przetwarzania od prezentacji.

Opis

Dane

Dane pozostają "czym jest system ". Część danych architektury DCI to (względnie) statyczny model danych z relacjami . Projekt danych jest zwykle kodowany jako konwencjonalne klasy reprezentujące podstawową strukturę domenową systemu. Te klasy są ledwie inteligentnymi danymi i wyraźnie brakuje im funkcjonalności charakterystycznej dla obsługi konkretnego przypadku użycia . Klasy te zwykle hermetyzują fizyczne przechowywanie danych. Dane te implementują strukturę informacji pochodzącą z mentalnego modelu użytkowników końcowych, ekspertów dziedzinowych, programistów i innych osób w systemie. Mogą one ściśle odpowiadać modelowym obiektom MVC.

Przykładem obiektu danych może być konto bankowe. Jego interfejs miałby podstawowe operacje zwiększania i zmniejszania salda oraz zapytania o aktualne saldo. Interfejs prawdopodobnie nie oferowałby operacji obejmujących transakcje lub które w jakikolwiek sposób obejmują inne obiekty lub jakąkolwiek interakcję użytkownika. Na przykład, chociaż konto bankowe może oferować prymitywną metodę zwiększania salda, nie będzie miało metody zwanej depozytem . Takie operacje należą natomiast do części interakcji DCI.

Obiekty danych to instancje klas, które mogą pochodzić z projektowania opartego na domenach , a takie klasy mogą wykorzystywać relacje podtypów do organizowania danych domeny. Chociaż ostatecznie sprowadza się to do klas, DCI odzwierciedla model obliczeniowy zdominowany przez myślenie obiektowe, a nie myślenie klasowe. Dlatego myślenie o „danych” w DCI oznacza myślenie bardziej o instancjach w czasie wykonywania niż o klasach, z których zostały utworzone.

Kontekst

Kontekst to klasa (lub jej instancja), której kod zawiera Role dla danego algorytmu, scenariusza lub przypadku użycia, a także kod mapujący te Role na obiekty w czasie wykonywania i realizujący przypadek użycia. Każda Rola jest powiązana z dokładnie jednym obiektem podczas dowolnego uchwalania przypadków użycia; jednakże pojedynczy obiekt może jednocześnie pełnić kilka Ról. Kontekst jest tworzony na początku wdrażania algorytmu, scenariusza lub przypadku użycia. Podsumowując, kontekst obejmuje przypadki użycia i algorytmy , w których obiekty danych są używane przez określone Role.

Każdy kontekst reprezentuje jeden lub więcej przypadków użycia. Obiekt kontekstu jest tworzony dla każdego przypadku użycia, za który jest odpowiedzialny. Jego głównym zadaniem jest zidentyfikowanie obiektów, które będą uczestniczyć w przypadku użycia i przypisanie im ról, które realizują przypadek użycia poprzez swoje obowiązki. Rola może obejmować metody, a każda metoda jest małą częścią logiki algorytmu implementującego przypadek użycia. Metody roli działają w kontekście obiektu wybranego przez kontekst do odegrania tej roli w bieżącym przypadku użycia. Powiązania roli z obiektem, które mają miejsce w kontekście, można skontrastować z polimorfizmem języka programowania obiektowego. Ogólna funkcjonalność biznesowa jest sumą złożonych, dynamicznych sieci metod zdecentralizowanych w wielu kontekstach i ich rolach.

Każdy kontekst jest zakresem zawierającym identyfikatory odpowiadające jego rolom. Każda rola wykonywana w tym kontekście może odwoływać się do innych ról w tym kontekście za pośrednictwem tych identyfikatorów. Identyfikatory te zaczęto nazywać RoleMethods . W czasie wdrażania przypadków użycia każdy z tych identyfikatorów zostaje powiązany z obiektem odgrywającym odpowiednią Rolę w tym kontekście.

Przykładem kontekstu może być przelew bankowy między dwoma kontami, w którym modele danych (konta bankowe) są używane za pośrednictwem ról o nazwach SourceAccount i DestinationAccount.

Interakcja

Interakcja to „co robi system ”. Interakcja jest realizowana jako Role, które są odgrywane przez obiekty w czasie wykonywania. Obiekty te łączą stan i metody obiektu danych (domeny) z metodami (ale bez stanu, ponieważ Role są bezstanowe) z jednej lub więcej ról. W dobrym stylu DCI Rola odnosi się do innego obiektu tylko w kategoriach jego (bezmetodowej) Roli. Istnieje specjalna Rola zwana self , która wiąże się z obiektem odgrywającym bieżącą Rolę. Kod w metodzie Role może wywoływać metodę na sobie , a tym samym wywoływać metodę części danych bieżącego obiektu. Ciekawym aspektem DCI jest to, że te powiązania są gwarantowane tylko w czasie wykonywania (przy użyciu różnych podejść i konwencji; szablony C++ mogą być używane do zagwarantowania, że powiązania się powiodą). Oznacza to, że interakcje, metody Role, są ogólne . W rzeczywistości niektóre implementacje DCI używają ogólnych lub szablonów dla ról.

Rola to bezstanowa konstrukcja programistyczna, która odpowiada umysłowemu modelowi użytkownika końcowego jakiejś jednostki w systemie. Rola reprezentuje zbiór obowiązków. Podczas gdy językowe programowanie obiektowe mówi o obiektach lub klasach jako o wielu obowiązkach, DCI przypisuje je do ról. Obiekt uczestniczący w przypadku użycia ma obowiązki: te, które bierze na siebie w wyniku pełnienia określonej Roli. Większość nowoczesnych języków programowania ma sposób wyrażania ról i wyrażania wstrzykiwania metod ról do obiektów, a techniki implementacji różnią się w zależności od języka. Wstrzykiwanie może być w pełni dynamiczne w czasie wykonywania w językach takich jak Ruby i Python ; jest bardziej statyczny w językach takich jak Smalltalk - Squeak , Scala i C++ . Środowisko programistyczne Qi4j oferuje sposób wyrażania wstrzykiwania metody Role do obiektów Java. Domyślna metoda Java 8 na interfejsach może być używana do implementacji ról w sposób bezpieczny dla typów.

Na przykład w powyższym przypadku użycia przelewu pieniężnego metody Role w SourceAccount i DestinationAccount realizują rzeczywisty transfer.

Cechy wyróżniające DCI

DCI ogranicza wszystkie dozwolone sieci komunikujących się obiektów do sieci, które mają wspólne topologie, po jednej dla każdego przypadku użycia. Takie sieci są jawne w interakcjach między rolami DCI, podczas gdy w klasycznej orientacji obiektowej są wyłaniające się. Rola jest węzłem w takiej topologii; jest to częściowa klasyfikacja zachowań wszystkich obiektów, które mogą zajmować ten węzeł. Topologia to opis struktury systemu w czasie wykonywania.

Program zorientowany obiektowo to złożona i dynamiczna sieć obiektów, w tym samym sensie, w jakim relacje między obiektami świata rzeczywistego są złożone i dynamiczne. Wyobraź sobie kelnera w restauracji. Sam kelner jest złożonym obiektem, który można postrzegać na wiele sposobów: jako mój Kelner (np. opisujący dzisiejsze menu i przyjmujący moje zamówienie), jako Pracownik restauracji (z określoną pensją i godzinami pracy) oraz jako Osoba w restauracji (w której obowiązuje ograniczenie liczby osób do 150). Gdyby klasa Waiter została napisana w celu uchwycenia rzeczywistej istoty Kelnerów (na czym tak naprawdę polega orientacja obiektowa), musiałaby być bardzo złożona, aby obsługiwać wszystkie te perspektywy.

W DCI te różne poglądy są uwzględniane w rolach. W czasie wykonywania Rola jest tożsamością obiektu. Podczas odgrywania przypadku użycia (np. Serve the Wine ) Rola Kelnera jednoznacznie identyfikuje pojedynczy obiekt w danym momencie. Możesz argumentować, że przy stole może być kilku Kelnerów. Jednak mogą one różnić się obowiązkami w ramach przypadku użycia , na przykład w nazwach ról HeadWaiter i Busboy. Nawet jeśli ich obowiązki są identyczne, nadal byliby opisani jako Kelner-1 i Kelner-2 lub jako indywidualne (nazwane) elementy wektora Waiter, gdyby ktoś zamierzał napisać dla nich oprogramowanie. Tak więc rola taka jak HeadWaiter staje się identyfikatorem, uchwytem, za pomocą którego obiekty odnoszą się do siebie w przypadku użycia .

DCI rozpoznaje Kelnera jako obiekt, a nie, powiedzmy, kompozycję części Pracownika, części Kelnera i części Osoby. Obiekt ma swoją własną tożsamość niezależną od przypadku użycia ; to jest aspekt danych DCI. Role są aliasami nazw swoich obiektów, ale same nigdy nie są oddzielnymi obiektami; co spowodowałoby schizofrenię u siebie . W tym sensie każdy Kelner jest homo sapiens . To jest elementarna część Kelnera o tym, czym jest system. Obiekt ma wiele możliwych tożsamości w zależności od przypadku użycia, w którym jest zaangażowany; ujawnia się to w Tożsamościach ról, które stanowią część aspektu Interakcja DCI. Są to (zwykle bardziej interesujące) części tego, co robi system. Jednak w DCI istnieje tylko jeden obiekt , który przenosi obie te perspektywy w czasie wykonywania. Perspektywy te mogą być różnie pogrupowane w czasie kodowania. W kodzie dominuje przypadków użycia , która przecina obiekty i która jest również częścią aspektu interakcji DCI.

DCI pozwala obiektowi przyjąć jedną lub więcej ról podczas realizacji przypadku użycia . Innymi słowy, obiekt jest ponownie powiązany z identyfikatorami ról w każdym przypadku użycia . Role te określają interfejs, określany jako typ roli. Każdy obiekt jest „odtwarzany” (w sensie teatralnym) na nowo w każdym przypadku użycia . Chociaż Rola jest powiązana tylko z jednym obiektem, obiekt może odgrywać kilka Ról. Na przykład Główny Kelner może być zaangażowany w przypadek użycia polegający na liczeniu wszystkich osób przebywających w restauracji podczas inspekcji przeciwpożarowej i będzie pełnił zarówno Rolę Osoby, jak i Głównego Kelnera. Pojedynczy obiekt obsługuje zachowania obu Ról niezbędnych do realizacji przypadku użycia .

Podsumowując, architektury DCI zazwyczaj charakteryzują się następującymi właściwościami:

Model danych odzwierciedla strukturę domeny, a nie partycje jej zachowania;
Obiekty dynamicznie przyjmują Role podczas realizacji przypadków użycia ;
Każdą Rolę przypadku użycia odgrywa obiekt określony przez Kontekst na początku uchwalenia przypadku użycia ;
Sieć interakcji między rolami w kodzie (tj. w czasie kodowania) jest taka sama jak odpowiednia sieć obiektów w czasie wykonywania;
Sieci te są potencjalnie odtwarzane przy każdym przypadku użycia ;
Role wchodzą i wychodzą z zakresu w zależności od okresu życia przypadków użycia , ale obiekty, które mogą pełnić te Role, mogą trwać przez wiele okresów życia przypadków użycia i potencjalnie mogą odgrywać wiele ról w swoim własnym życiu.

Model wykonania

DCI można traktować jako paradygmat programowania sterowanego zdarzeniami , w którym pewne zdarzenie (jako ludzki gest w architekturze model-widok-kontroler (MVC)) uruchamia przypadek użycia . Przypadek użycia może być krótkotrwały lub długotrwały. Zdarzenia nazywane są wyzwalaczami i są obsługiwane w środowisku , w którym osadzone jest DCI. To środowisko może być kontrolerem konwencjonalnej architektury MVC lub dowolnym innym kodem na poziomie systemu.

Wyzwalacz powoduje, że środowisko tworzy instancję obiektu kontekstu . Typ obiektu jest wybierany zgodnie z rodzajem przypadku użycia , który nastąpi, na podstawie informacji o wyzwalaczu lub stanie systemu lub obu. Na przykład bankomat może mieć osobne klasy kontekstu dla przelewów pieniężnych, wypłat, depozytów, zapytań o saldo i tak dalej. Gdy środowisko utworzy instancję obiektu Context, wywołuje swoją metodę wyzwalającą , aby rozpocząć realizację przypadku użycia.

Jak opisano powyżej, każdy Kontekst zapewnia zakres projektowy dla Ról, które uczestniczą w realizacji przypadków użycia . Zadaniem kontekstu jest przypisanie obiektów do odgrywania tych ról.

Kontekst najpierw znajduje obiekty, które mają wziąć udział w tym uchwaleniu przypadku użycia . Obiekty te mogą znajdować się w dowolnym miejscu w środowisku lub w bazie danych lub mogą być tworzone w locie; DCI nie ogranicza tych obiektów. W ramach Kontekstu istnieje co najwyżej jedna instancja pełniąca daną Rolę w danym momencie.
Po drugie, kontekst przypisuje pojedynczy obiekt do odgrywania każdej ze swoich ról (chociaż pojedynczy obiekt często odgrywa wiele ról w jednym kontekście). W silnie dynamicznych językach (Ruby, Python) kontekst wstrzykuje metody Role do obiektu. W większości dynamicznych języków każdy istniejący obiekt może zostać poproszony o odegranie dowolnej roli w dowolnym momencie (chociaż niektóre kombinacje obiekt-rola mogą oczywiście nie mieć sensu; nonsensowne kombinacje obiektów i ról skutkowałyby komunikatem WIADOMOŚĆ NIEZROZUMIANA w czasie wykonywania, gdyby rola metody zostały wywołane.) W językach o bardziej statycznym typie (Scala, C++) musiało istnieć jakieś wcześniejsze ustawienie dla obiektu obsługującego metody Role. Na przykład Scala tworzy anonimową klasę, która łączy elementarną logikę klasy domenowej z logiką przypadku użycia cechy użytej do zaimplementowania roli; Role są skutecznie przypisywane do obiektów domeny podczas ich tworzenia.
Po trzecie, kontekst wywołuje metodę Role na pierwszym obiekcie, który ma wziąć udział w przypadku użycia .
Od tego momentu Role odwołują się do swoich metod w celu realizacji przypadku użycia . Metoda Role może wywoływać metodę na sobie , która w rzeczywistości jest obsługiwana przez obiekt aktualnie odgrywający Rolę. W ten sposób Role odwołują się do podstawowych operacji na danych obiektów, które aktualnie je odtwarzają.

Wdrażanie DCI

DCI opiera się na procesie projektowania, który oddziela przypadki użycia od modelu danych. Model danych jest często oparty na nieformalnej analizie domeny. Role charakteryzujące model funkcjonalności systemu użytkownika końcowego pochodzą z przypadków użycia .

Techniki implementacji różnią się w zależności od języka programowania. Wspólną cechą wielu podejść jest to, że Role są reprezentowane przez takie konstrukty, jak generyczne, szablony, klasy lub cechy . Kod dla podstawowej logiki domeny jest implementowany oddzielnie, zgodnie z konwencjonalną praktyką zorientowaną obiektowo i najczęściej przy użyciu klas. Kod każdej roli jest wstrzykiwany do obiektu domeny, który będzie odgrywał go podczas przypadku użycia . Aby zaimplementować Roles , zwykle potrzebne jest wstrzyknięcie metody. Cechy to jedna z powszechnych technik języka programowania wspierająca wstrzykiwanie metody. Niektóre języki, takie jak Scala , mają natywną obsługę cech , podczas gdy inne języki (np. Ruby i Python ) umożliwiają wstrzykiwanie metod w czasie wykonywania. W Javie do obsługi DCI potrzebne są sztuczki prekompilatora oparte na adnotacjach. Haxe wykorzystuje swoją funkcję makr w czasie kompilacji, aby przekształcić semantykę DCI w kod języka docelowego.

stronie fulloo.info, prowadzonej przez twórców DCI, istnieje kilka przykładowych implementacji .

Historia

DCI został wynaleziony przez Trygve Reenskaug , również wynalazcę MVC. Obecne sformułowanie DCI jest głównie dziełem Reenskauga i Jamesa O. Copliena .

DCI powstało w dużej mierze jako następstwo pracy Trygve Reenskauga nad modelowaniem opartym na rolach. Trygve od dawna zdawał sobie sprawę, że Role odgrywają kluczową rolę w sposobie, w jaki programiści myślą o obiektach, i że oparty na klasach postęp technologii języka programowania odebrał znaczną część motywacji do myślenia o obiektach w programie. To z kolei utrudniało wnioskowanie o programie w czasie wykonywania. Co więcej, fakt, że obiektowe języki programowania oferowały jedynie klasy do wyrażania logiki programu, pozostawił programistę na łasce strukturalnego układu danych w celu określenia zachowania, co jest nienaturalne w porównaniu z zachowaniem wyznaczającym granice ról. To z kolei sprawiło, że zachowanie programu było trudniejsze do uzasadnienia niż, powiedzmy, program proceduralny w Fortranie . ^{[ potrzebne źródło ]}

Trygve uznał, że ważne jest stworzenie struktur programu, o których można wnioskować, i zaczął uspołeczniać te pomysły już w 2000 roku. Do 2006 roku miał działający model projektu, a jego odkrycie w 2008 roku pracy Schärliego nad cechami dostarczyło kamienia zwornikowego, który zapewni naturalny język programowania wyrażający te idee. Prototypował pomysły w środowisku programistycznym Baby, napisanym w Squeak. James Coplien dołączył do Trygve około 2007 roku iw połowie 2008 roku miał prototyp działający w C++ . Steen Lehmann, Rickard Öberg i Niclas Hedhman przyspieszyli adaptację tych pomysłów do Rubiego i Javy w ciągu mniej więcej następnego roku dzięki frameworkowi Qi4j. Wiele dodatkowych adaptacji językowych nastąpiło po sesji na konferencji JaOO w Danii we wrześniu 2008 roku. W 2010 roku Rune Lund-Søltoft stworzył język Marvin. Była to pierwsza kompilacja języka z natywną obsługą DCI. Marvin miał głównie służyć jako dowód koncepcji, aby zaprezentować ideę „bezwtryskowego DCI”. Większość poprzednich implementacji zmieniała obiekty role player w sposób, który byłby widoczny poza kontekstem. James Coplien stworzył język trygve oparty na tym samym pomyśle, pierwszy język zbudowany od podstaw w celu obsługi DCI.

Różne podejścia przyjęte do ewolucji programowania obiektowego, zarówno na poziomie języka, jak i wzorców , w różnym stopniu zgadzają się z DCI:

Mixiny to sposób enkapsulacji kodu dla określonej funkcjonalności systemu w zamkniętej formie; jednak nie ma spójnego mechanizmu łączenia wielu domieszek w jednostkę na poziomie przypadku użycia . Można je wykorzystać do realizacji koncepcji Role w DCI, choć nie w ścisłym tego słowa znaczeniu. ^{[ potrzebne źródło ]}
Wielokrotna wysyłka była wczesną próbą pełniejszego oddzielenia algorytmu od obiektów, które były zaangażowane w jego wykonanie, co można uzupełnić o oddzielenie przez DCI typowych powtarzających się algorytmów od fragmentów kodu, które można indywidualnie zlokalizować w poszczególnych obiektach. Koncepcja DCI prowadzi do szerszego ponownego wykorzystania pojedynczego algorytmu w formie zamkniętej w wielu zestawach obiektów o bardzo heterogenicznych typach. Obiekt kontekstu DCI działa jak jawny, inteligentny dyspozytor, który jest analogiczny do mechanizmów wysyłania w językach z wieloma wysyłaniami. ^{[ potrzebne źródło ]}
Prawdziwie zorientowane obiektowo języki programowania, takie jak Self, próbują przełamać dychotomię między domenami programowania klasowego i obiektowego wykonywania, co pomaga programistom skupić się na obiektach czasu wykonywania. DCI przywraca wiedzę na poziomie kodu o relacjach między nimi w kontekstach oraz w relacjach statycznych między metodami Role.
Wstrzykiwanie zależności to od dawna stosowane podejście do zmiany funkcjonalności obiektu w czasie wykonywania poprzez umożliwienie mu „zlecenia” części wykonania obiektowi zewnętrznemu, który można dowolnie ponownie powiązać. Większość implementacji ^{[ które? ]} wstrzykiwania zależności prowadzi do problemu schizofrenii jaźni , który implementacje DCI właściwie rozwiązują. Systemy takie jak Elmo wykorzystują to podejście, które wprowadza dodatkową złożoność w celu rozwiązania niejednoznaczności metod i zduplikowanych nazw elementów danych. ^{[ potrzebne pełne cytowanie ]}
Projektowanie wieloparadygmatowe próbuje oddzielić zachowanie i strukturę poprzez dostosowanie zachowania do projektu proceduralnego, a komponentu strukturalnego do obiektów, umożliwiając swobodny dostęp między nimi, zgodnie z zasadami projektowania C++. Podejście DCI może poprawić wyrażanie relacji między częściami proceduralnymi i strukturalnymi projektu oraz ogólną spójnością.

Wyzwaniom programowania obiektowego można również sprostać, rozwiązując jego problemy na poziomie paradygmatu.

Programowanie zorientowane aspektowo (AOP) jest prawdopodobnie najbliższym historycznie spokrewnionym z DCI. Większość zastosowań Aspektów jest ściśle powiązana z perspektywą programisty i wymaga silnego wsparcia narzędziowego, aby zapewnić dobre zrozumienie zachowania oprogramowania w dowolnym punkcie cięcia . Główna różnica polega na tym, że w DCI struktura algorytmu jest pierwotna, z silnym naciskiem na jego izolację od kodu na zewnątrz, poprawiając czytelność kodu. W AOP punkt cięcia i porada mają jednakowe znaczenie i chociaż fizycznie nie są ze sobą połączone, muszą być rozumiane razem, aby zrozumieć kod, ponieważ porada jest inwazyjna w punkcie cięcia . Podczas gdy AOP zapewnia administracyjne grupowanie powiązanego zbioru indywidualnych modyfikacji lokalnych, które razem przecinają podstawową strukturę kodu, DCI jest semantycznym wyrazem algorytmu z pierwszorzędną analizą, który wywołuje istniejące metody obiektowe. DCI można traktować jako sposób na skorzystanie z dużej porady i umożliwienie wstrzyknięcia jej części do szeregu regularnych cięć punktowych . ^{[ potrzebne źródło ]}
Programowanie zorientowane na role łączy pomysły z programowania aspektowego , modelowania koncepcyjnego i nie tylko. Wczesne próby (1991) definiowały role w sposób niezależny, ale nowsze podejścia (2002 i następne) zbiegają się w podkreślaniu, że role zależą od kontekstu (także „zespołów” lub „instytucji”). W programowaniu zorientowanym na role role są definiowane w odniesieniu do jakiejś wewnętrznej (lub podstawowej) jednostki, co odpowiada dychotomii role-dane w DCI. Pojęcie kontekstu jest zasadniczo takie samo w obu podejściach. Oba podejścia kładą nacisk na interakcję między grupą ról.

Można zidentyfikować kilka różnic. Programowanie zorientowane na role koncentruje się na dodawaniu obsługi ról do obiektowych języków programowania , w których nacisk kładzie się na zwiększenie wyrazistości języka programowania i umożliwienie większej liczby projektów. Dla porównania, DCI kładzie większy nacisk na metodę uchwycenia modeli mentalnych, definiując tę metodę częściowo jako ograniczenia tego, co należy uznać za projekt prawny odpowiadający DCI. Na przykład: Autorzy DCI zwykle zniechęcają do korzystania z dziedziczenia (np. „w ramach DCI nie dziedziczy się ról”), podczas gdy programowanie zorientowane na role obejmuje (a nawet ulepsza) dziedziczenie jako centralną koncepcję programowania obiektowego, wspierając dowolne kombinacje z innymi koncepcjami. DCI podkreśla, że należy unikać autoschizofrenii , podczas gdy programowanie zorientowane na role twierdziło, że zarządza podzielonymi obiektami w taki sposób, że schizofrenia nie jest już problemem, ale ułatwia tworzenie bardziej elastycznych projektów. Późniejszy artykuł autorów DCI twierdzi, że autoschizofrenia pozostaje problemem w programowaniu zorientowanym na role, używając kontrprzykładu opartego na zmodyfikowanej implementacji algorytmu Dijkstry . W związku z tym DCI poświęca zalety dziedziczenia w celu całkowitego uniknięcia swoich niedociągnięć, podczas gdy programowanie zorientowane na role przyjmuje podejście łagodzące, przywiązując wagę do zrównoważenia niebezpieczeństw z jego popularnymi zaletami.

Badania

Badanie przeprowadzone w 2017 roku przez Héctor Valdecantos et. glin. pokazał, że „Analiza poprawności pokazuje, że programiści z grupy DCI radzili sobie lepiej niż programiści z grupy OOjava. Jest to zgodne z teoriami stojącymi za DCI i powinno zachęcać do dalszych i systematycznych badań dotyczących możliwości tego paradygmatu”.

Według badaczy Bluemke i Stępień z Instytutu Informatyki Politechniki Warszawskiej „Systemy oparte na DCI są znacznie bardziej elastyczne niż tradycyjne, wynika to z faktu, że części statyczne (Dane) i dynamiczne (Kontekst, Interakcja) systemu są rozdzielone, a oddzielenie problemów jest bardzo potężną strategią opanowania złożoności”.

Linki zewnętrzne