Az adat-kontextus-interakció (DCI) a számítógép-programozás egyik paradigmája, egymással kommunikáló objektumok elkészítéséhez. Céljai: Az objektumorientált kód olvashatóság javítása azzal, hogy a rendszer viselkedése egyenrangú az objektumokkal A lassan változó rendszerről való tudás és a gyakran változó viselkedés elkülönítése, ahelyett, hogy a kettőt egyesítenénk egy interfészben Segít megindokolni a fejlesztőknek, hogy rendszerszintű állapotról és viselkedésről tudjanak gondolkodni, az objektumok állapotával és viselkedésével szemben
A paradigma elkülöníti a zip tartománymodellt (adatok), a használati esetektől (kontextus) és a szerepektől (interakció). A modell-nézet-vezérlő kiegészítője. A modell-nézet-vezérlő tovább használható, mint mintanyelv, hogy elkülönítse az adatokat, feldolgozásukat és megjelenítésüket.
Leírása Adatok Az adatok arra a kérdésre adnak választ, hogy: Mi ez a rendszer? Az adatok javarészt statikus adatmodellekből és kapcsolataikból állnak. Az adatszerkezeteket hagyományos osztályokként valósítják meg. Használati eseteket nem valósítanak meg, azokat az interakció határozza meg. Kezelik a fizikai adattárakat, és tartalmazzák a felhasználó és a többi részt vevő által megadott mentális modellt. A modell-nézet-vezérlő modelljére emlékeztetnek.
Az adat objektumra példa egy bankszámla. Interfésze tartalmazná az egyenleg lekérdezését, továbbá a betételt és a kivételt a számlára, illetve számláról. Az interfész nem tartalmaz tranzakciókat, vagy olyan metódusokat, amelyek más objektumokat vagy felhasználói közreműködést igényelnek. A bankszámla tartalmaz egy primitív műveletet a betét növelésére, de a deposit műveletet az interakcióra hagyja.
Az adatobjektumok osztályai származhatnak tartományvezérelt fejlesztésből, így állhatnak altípus kapcsolatban az adatok rendszerezésére. Habár ez csökkenti az osztályok számát, az adat-kontextus-interakció olyan számítástechnikai modellt tükröz, ami inkább objektumokban, mint osztályokban gondolkodik. Emiatt, amikor adatokról van szó, sokkal inkább a futási időben létrejövő példányokra gondolunk, mint az osztályokra. Kontextus A kontextus tagjai azok az osztályok, amelyek példányai egy algoritmus, egy jelenet vagy használati eset szerepeit valósítják meg, vagy ezeket futási időben objektumokra vetítik, és feldolgozzák a használati esetet. Egy szerep pontosan egy objektumhoz kapcsolódik; megfordítva viszont egy objektum több szerepet is betölthet. A kontextus a megfelelő algoritmus hívásakor, jelenet kezdetekor vagy használati eset indulásakor példányosul. Összegezve, a kontextus kapcsolja össze az adatokat és az algoritmusokat.
A kontextusosztályok megfeleltethetők egy vagy több használati esetnek, jelenetnek vagy algoritmusnak. A kontextusobjektum feladata, hogy azonosítsa a részt vevő objektumokat, és szerepeket társítson hozzájuk, amely szerepnek megfelelő felelősséget kapnak. Társíthatja a metódusokat, amelyek mindegyike az adott használati esetnek, jelenetnek vagy algoritmusnak egy kis részének logikáját valósítja meg. A szerep által végrehajtott metódusként a szerepre kiválasztott objektum metódusa hívódik meg. A kontextus által megvalósított kapcsolat párba állítható az objektumorientáció által létrehozott polimorfizmussal. Az általános üzleti funkcionalitás komplex, dinamikus algoritmusok összessége, amelyeket több kontextus és többszörös kontextusok és az azokban levő szerepek decentralizálnak.
Minden kontextusnak saját hatóköre van, ami magában foglal azonosítókat, amelyek megfelelnek a szerepeknek. A kontextusban szereplő objektumok ezekkel a nevekkel hivatkozhatnak egymásra. Ezek az azonosítók metódus nélküli szerepek. Végrehajtás közben ezek a nevek a megfelelő szerepet betöltő objektumhoz vannak hozzárendelve.
Kontextusra lehet példa két végpont közötti adatátvitel, ahol a SourceAccount és a DestinationAccount szerepek használják az adatmodelleket (bankszámlák).
Interakció Az interakció arra a kérdésre felel, hogy: mit csinál a rendszer? Az interakciókat szerepekként valósítják meg, amiket objektumok töltenek be futásidőben. Ezek az objektumok kombinálják az adatmodellek állapotait és metódusait egy vagy több szerep metódusaival. A szerepek állapotával nem kell számolni, mivel a szerepeknek nincs állapota. Jó stílusban az objektumok csak szerepükkel hivatkoznak egymásra. A self is szerep, csak speciális; ez kapcsolja össze az objektumot a szerepével. A szerep metódusa ezen keresztül hívhatja az objektum metódusát. Ezek a kapcsolatok csak futásidőben állnak fenn; ehhez használnak generikusokat, sablonokat, hogy a kötés mindig létrejöjjön, habár maga a minta nem teszi ezt kötelezővé.
A szerepek megfelelnek a felhasználó mentális modelljeinek a rendszerben levő entitásokról. A szerep felelősségek egy csoportját foglalja magába. Míg a klasszikus objektumorientált programozásban az objektumok és osztályok foglalják magukban a felelősséget, addig a minta ezeket a szerepeknek tulajdonítja. Egy használati esetben levő objektumnak felelősségei vannak, amiket a szerepe határoz meg. A legtöbb modern programozási nyelvben van lehetőség nyelvi szinten is leírni szerepeket, és a szerep metódusok injektálhatók objektumokba, de a megvalósítás módja nyelvfüggő. Az injekció lehet teljesen dinamikus, futásidejű, mint a Rubyhoz és a Pythonhoz hasonló nyelvekben, és statikus más nyelvekben, mint Smalltalk-Squeak, Scala és C++. A Qi4j programozási környezet szintén módot ad a szerep injektálására Javában.Qi4j framework A Java 8 interfészeinek alapértelmezett metódusa használható arra, hogy a szerepeket típusbiztosan meg lehessen valósítani.
Példánkban a SourceAccount és DestinationAccount szerepek elvégzik az átutalást.
Sajátosságai A minta az objektumok kommunikációját a közös topológiájú hálózatokra korlátozza, amiből minden használati esethez tartozik egy. Ezek a hálózatok explicitek a szerepek közötti interakciókban, míg klasszikusan emergensek. A szerepek a topológiák pontjai; részlegesen osztályozzák az objektumok viselkedését, amelyek elfoglalhatják ezeket a csúcsokat. A topológia leírás a futásidejű rendszerről.
Egy objektumorientált program objektumok dinamikus és összetett rendszere, ugyanúgy, ahogy a valós objektumok is összetettek és dinamikusak. Tekintsünk egy pincért egy étteremben! A pincér maga is összetett objektum: az én pincérem, aki felveszi és kihozza a rendelésemet, az étterem alkalmazottja munkaidővel és fizetéssel, és egy személy az étteremben, akli a 150 fő között foglalkoztatva van. A Waiter (pincér) osztálynak mindezeket meg kell ragadnia.
Az adat-kontextus-interakció minta mindezeket az aspektusokat különböző szerepekre osztja. Futásidőben a szerep azonosítja az objektumot. Használati eset végrehajtása közben (például bor felszolgálása) a pincér egyértelműen azonosít egy objektumot egy adott időpontban. Lehet azzal érvelni, hogy több pincér lehet egy asztalnál, azonban a használati eset végrehajtása alatt különböző felelősséggel, például az egyik felveszi a rendelést, a másik kiszállítja. Ha egyeznek a felelősségek, akkor is különböző szerepnek kell tekinteni őket, megkülönböztethetők számokkal vagy egy tömb elemeiként. Így a szerep egyértelműen azonosítja az objektumot a használati esetben.
A minta egy objektumként kezeli a pincért, és nem úgy, mint ami különböző részekből, egy személyből, egy alkalmazottból és egy pincérből áll. Az objektum azonossága független a szerepétől; az adatokhoz tartozik. A szerepek csak aliasok, és nem önálló objektumok; ez skizofréniát okozna. Ebben az értelemben minden pincér ember. Ez a pincér alapvető része. Az objektum több különböző azonosságot vesz fel, attól függően, hogy milyen használati esetekben vesz részt; ez az interakció része. Egy szerep azonban egyszerre egy objektumhoz tartozik. Kódolási időben a szerepek különbözőképpen csoportosíthatók. A kód szerkezetét a használati esetek határozzák meg, amelyekben különböző időben különböző objektumok vehetnek részt; ez is az interakcióhoz tartozik.
Egy objektum több használati esetben is részt vehet, ezért különböző időpontokban más szerepet vehet fel. A szerepek interfészt valósítanak meg, amire szerep típusként hivatkoznak. Színházi értelemben az objektuok új szerepet kapnak minden használati esetben. Például a tűzvédelmi oktatáson a pincérünk az étterem egy alkalmazottja, és betölti a személy szerepet is.
Összesítve, a mintát a következők jellemzik: Az adatmodell a tartomány szerkezetét, és nem viselkedésének szerkezetét tükrözi. Az objektumok dinamikusan változó szerepeket töltenek be a használati esetek során. Minden használati eset kezdetén a kontextus határozza meg, hogy egy használati eset szerepeit mely objektumok töltik be. A szerepek közötti interakciók hálózata ugyanaz, mint végrehajtási időben az objektumok hálózata. Ez a hálózat dinamikusan változik a különböző használati esetek végrehajtása alatt. A szerepek hatókörét a használati eset időtartama határozza meg, de az egyes objektumok több használati esetet is túlélhetnek, miközben több szerepet játszanak különböző használati esetekben.
Végrehajtási modell A minta tekinthető eseményvezérelt paradigmának, ahol bizonyos események használati esetet indítanak. A használati eset lehet rövid, vagy hosszú élettartamú. Az eseményeket triggereknek nevezik, és egy környezetben hajtódnak végre, amibe a program be van ágyazva. A környezet lehet a modell-nézet-vezérlő vezérlője, vagy más rendszerszintű kód.
A trigger hatására a környezetben létrejön egy kontextus objektum. Az objektum típusát a végrehajtandó használati eset határozza meg, amit a triggertől érkező információ és a rendszer állapota határoz meg. Például egy pénztárgépnek különböző kontextusai lehetnek a különböző pénzügyi műveletek számára, mint egyenleg lekérdezése, betétel, kivétel, átutalás. A kontextus objektum elindítja a trigger metódust, hogy elindítsa a használati esetet.
Minden kontextus tartalmazza a részt vevő szerepeket, és a kontextus feladata, hogy objektumokat rendeljen hozzájuk a triggertől kapott információ és a rendszer állapota alapján. Az objektumok bárhol lehetnek a környezetben, lehet, hogy adatbázis tartalmazza, vagy lehet, hogy létre kell hozni őket; ezt a minta nem határozza meg. Egy kontextuson belül egy szerepet legfeljebb egy objektum tölt be.
Ezután a kontextus kiosztja a szerepeket az objektumok között. Egy objektum több szerepet is kaphat. Erősen típusos nyelvekben, mint a Ruby és a Python, a kontextus injektálja a szerepeket az objektumokba. A legtöbb dinamikus nyelvben bármely objektum felkérhető bármelyik szerepre, de a nem megfelelő kombináció MESSAGE NOT UNDERSTOOD hibaüzetet ad futás közben. Statikus típusozású nyelvekben (Scala, C++) az objektumok előzetes elrendezése biztosítja, Például a Scala névtelen osztályt hoz létre, ami a tartomány osztály logikáját kombinálja a szerep megalkotásához használt vonások használati eset logikájával. A szerepeket hatékonyan hozzárendelik példányosítás után a tartomány objektumokhoz.
A kontextus meghívja a használati eset első résztvevőjének szerep metódusát. Innentől kezdve a szerepek egymást hívják. Egy szerep a selfen hívhatja azt az objektumot is, ami azt a szerepet kapta.
Megvalósítása A minta olyan tervezési folyamaton alapul, ami megkülönbözteti az adatmodelleket a használati esetektől. Az adatmodell gyakran informális tartományelemzésen alapul. A rendszer funkcionalitásának végfelhasználói modelljét jellemző szerepek a használati esetekből származnak. A minta általános tervezésének egy általános megközelítése a karcsú architektúra,Lean Software Architecture web page, http://www.leansoftwarearchitecture.com amiről a Lean Architecture ír.James Coplien and Gertrud Bjørnvig, Lean Architecture for Agile Software Development. Wiley: 2010.