Daten, Kontext und Interaktion

Daten, Kontext und Interaktion (DCI) ist ein Paradigma, das in Computersoftware verwendet wird, um Kommunikationssysteme zu programmieren Objekte. Seine Ziele sind:

• Verbesserung der Lesbarkeit von objektorientierter Code durch Angabe des Status des Systemverhaltens.
• Code sauber für das schnell ändernde Systemverhalten sauber zu trennen (was für ein System tut) gegen langsam verändern Fachwissen (Was für ein System ist), anstatt beide in einer Klassenschnittstelle zu kombinieren;
• Softwareentwickler zu helfen, den Zustand und Verhalten auf Systemebene zu veräußert, anstatt nur den Objektzustand und nur zu einem Objektzustand und Verhalten;
• Um einen Denkstil des Objekts zu unterstützen, der den mentalen Modellen der Programmierer nahe stand, anstatt den Denkstil der Klassen, der das Objekt überschattete, früh in der Geschichte der objektorientierten Programmiersprachen zu denken.

Das Paradigma trennt die Domänenmodell (Daten von Anwendungsfälle (Kontext) und Rollen, die Objekte Play (Interaktion). DCI ergänzt sich zu Model View Controller (MVC). MVC als a Mustersprache wird immer noch verwendet, um die Daten und ihre Verarbeitung von der Präsentation zu trennen.

Beschreibung

Daten

Die Daten bleiben "Was das System ist." Das Daten Ein Teil der DCI -Architektur ist das (relativ) statische Datenmodell mit Beziehungen. Das Datendesign wird normalerweise als herkömmliche Klassen codiert, die die grundlegende Domänenstruktur des Systems darstellen. Diese Klassen sind kaum intelligente Daten, und ihnen fehlt ausdrücklich die Funktionalität, die für die Unterstützung eines bestimmten Lebensraums ist Anwendungsfall. Diese Klassen verkörpern üblicherweise die physische Speicherung der Daten. Diese Daten implementieren eine Informationsstruktur, die aus dem mentalen Modell von Endbenutzern, Domänenexperten, Programmierern und anderen stammt Personen Im System. Sie können eng mit den Modellobjekten von MVC entsprechen.

Ein Beispiel für ein Datenobjekt könnte ein Bankkonto sein. Die Schnittstelle hätte grundlegende Vorgänge, um das Gleichgewicht zu erhöhen und zu verringern und nach dem aktuellen Gleichgewicht zu fragen. Die Schnittstelle würde wahrscheinlich keine Operationen anbieten, die Transaktionen beinhalten oder in irgendeiner Weise andere Objekte oder eine Benutzerinteraktion beinhalten. Zum Beispiel, obwohl ein Bankkonto einen Primitiv für die Erhöhung des Guthabens anbietet, hätte es keine Methode aufgerufen Hinterlegung. Solche Operationen gehören stattdessen in den Interaktionsteil von DCI.

Datenobjekte sind Fälle von Klassen, aus denen möglicherweise stammen Domänengetriebenes Designund solche Klassen können Subtyping -Beziehungen verwenden, um Domänendaten zu organisieren. Obwohl es sich am Ende auf Klassen reduziert, spiegelt DCI ein Rechenmodell wider, das eher vom Objekt Denken als von Klassendenken dominiert wird. Wenn Sie daher "Daten" in DCI denken, bedeutet dies daher mehr über die Instanzen zur Laufzeit als über die Klassen, aus denen sie instanziiert wurden.

Kontext

Der Kontext ist die Klasse (oder ihre Instanz), deren Code das enthält Rollen Für einen bestimmten Algorithmus, Szenario oder Anwendungsfall sowie der Code, um diese Rollen zur Laufzeit in Objekte zuzuordnen und den Anwendungsfall zu verabschieden. Jede Rolle ist während eines bestimmten Anwendungsfallvereinflusses an genau ein Objekt gebunden. Ein einzelnes Objekt kann jedoch gleichzeitig mehrere Rollen spielen. Ein Kontext wird zu Beginn des Erlasss eines Algorithmus, eines Szenarios oder eines Anwendungsfalls instanziiert. Zusammenfassend umfasst ein Kontext Anwendungsfälle und Algorithmen in welchen Datenobjekten in bestimmten Rollen verwendet werden.

Jeder Kontext repräsentiert einen oder mehrere Anwendungsfälle. Ein Kontextobjekt wird für jede Inszenierung eines Anwendungsfalls instanziiert, für den es verantwortlich ist. Seine Hauptaufgabe besteht darin, die Objekte zu identifizieren, die am Anwendungsfall teilnehmen, und sie den Rollen zuzuweisen, die den Anwendungsfall durch ihre Verantwortlichkeiten erfüllen. Eine Rolle kann Methoden umfassen, und jede Methode ist ein kleiner Teil der Logik eines Algorithmus, der einen Anwendungsfall implementiert. Rollenmethoden im Kontext eines Objekts, das im Kontext ausgewählt wird, um diese Rolle für die aktuelle Anwendungsfallvereinigung zu spielen. Die Rollen-zu-Objekt-Bindungen, die in einem Kontext stattfinden, können mit dem Polymorphismus der einheimischen objektorientierten Programmierung kontrastiert werden. Die allgemeine Geschäftsfunktionalität ist die Summe komplexer, dynamischer Netzwerke von Methoden, die in mehreren Kontexten und ihrer Rollen dezentral sind.

Jeder Kontext ist ein Umfang, der Kennungen enthält, die seinen Rollen entsprechen. Jede Rolle, die in diesem Kontext ausgeführt wird, kann sich auf die anderen Rollen in diesem Kontext durch diese Kennungen beziehen. Diese Kennungen sind gerufen worden Methodlose Rollen. Bei Anwendungsfallzeiten wird jeder dieser Kennungen an ein Objekt gebunden, das die entsprechende Rolle für diesen Kontext spielt.

Ein Beispiel für einen Kontext könnte eine Drahtübertragung zwischen zwei Konten sein, in denen Datenmodelle (die Bankkonten) über Rollen mit dem Namen SourceAcount und DestinationAccount verwendet werden.

Interaktion

Die Interaktion ist "Was das System tut. "Die Interaktion wird als Rollen implementiert, die von Objekten zur Laufzeit gespielt werden. Diese Objekte kombinieren den Zustand und die Methoden eines Datenobjekts (Domänen-) Objekt mit Methoden (aber kein Zustand, wie die Rollen staatenlos sind) aus einer oder mehreren Rollen. Guter DCI -Stil, eine Rolle spricht ein anderes Objekt nur in Bezug auf seine (methodlose) Rolle an. Es gibt eine besondere Rolle, die genannt wird selbst was an das Objekt bindet, das die aktuelle Rolle spielt. Der Code innerhalb einer Rollenmethode kann eine Methode auf aufrufen selbst und dadurch auf eine Methode des Datenteils des aktuellen Objekts aufzurufen. Ein merkwürdiger Aspekt von DCI ist, dass diese Bindungen nur zur Laufzeit garantiert sind (unter Verwendung einer Vielzahl von Ansätzen und Konventionen; C ++ - Vorlagen Kann verwendet werden, um zu garantieren, dass die Bindungen erfolgreich sein werden). Dies bedeutet, dass Interaktionen, die Rollenmethoden, sind generisch. Tatsächlich verwenden einige DCI -Implementierungen Generika oder Vorlagen für Rollen.

Eine Rolle ist ein staatenloser Programmierkonstrukt, das dem mentalen Modell des Endbenutzers einer Entität im System entspricht. Eine Rolle repräsentiert eine Sammlung von Verantwortlichkeiten. Während einheimisches, objektorientiertes Programmieren von Objekten oder Klassen als Multiplizität von Verantwortlichkeiten spricht, schreibt DCI sie Rollen zu. Ein an einem Anwendungsfall beteiligter Objekt hat Verantwortlichkeiten: diejenigen, die es aufgrund des Spielens einer bestimmten Rolle übernimmt. Die meisten modernen Programmiersprachen bieten eine Möglichkeit, Rollen auszudrücken und die Injektion von Rollenmethoden in Objekte auszudrücken, und die Implementierungstechniken variieren je nach Sprache. Die Injektion kann bei Laufzeit in Sprachen wie vollständig dynamisch sein Rubin und Python; Es ist in Sprachen wie statischer Smalltalk-Quietschen, Scala und C ++. Die QI4J -Programmierumgebung bietet eine Möglichkeit, die Injektion von Rollenmethoden in Java -Objekte auszudrücken.^[1] Java 8 Standardmethode Auf Schnittstellen können Rollen auf typeafe -Weise implementiert werden.

In der obigen Geldübertragungsnutzungsfall werden beispielsweise die Rollenmethoden in der SourceAccount und DestinationAccount die tatsächliche Übertragung erlassen.

Unterscheidungsmerkmale von DCI

DCI begrenzt alle zulässigen Netzwerke der Kommunikation von Objekten in Netzwerke, die gemeinsame Topologien teilen, eine für jeden Anwendungsfall. Solche Netzwerke sind in den Wechselwirkungen zwischen DCI -Rollen explizit, während sie in der klassischen Objektorientierung auftreten. Eine Rolle ist ein Knoten in einer solchen Topologie; Es ist eine teilweise Klassifizierung des Verhaltens aller Objekte, die diesen Knoten besetzen können. Die Topologie ist eine Beschreibung der Laufzeitstruktur eines Systems.

Ein objektorientiertes Programm ist ein komplexes und dynamisches Netzwerk von Objekten, in dem gleichen Sinne, dass Beziehungen zwischen realen Objekten komplex und dynamisch sind. Betrachten Sie einen Kellner in einem Restaurant. Der Kellner selbst ist ein komplexes Objekt, das in vielerlei Hinsicht angesehen werden kann: als mein Kellner (z. Person im Restaurant (mit einer Belegungsbeschränkung von 150 Personen). Wenn eine Kellnerklasse geschrieben würde, um die reale Essenz von Kellnern zu erfassen (worum es sich wirklich darum kümmert), müsste es sehr komplex sein, all diese Perspektiven zu unterstützen.

In DCI werden diese unterschiedlichen Ansichten in Rollen berücksichtigt. Zur Laufzeit ist die Rolle die Identität des Objekts. Während des Erlasss von a Anwendungsfall (wie Den Wein servieren) Die Rolle Kellner identifiziert eindeutig ein einzelnes Objekt zu einem bestimmten Zeitpunkt. Sie könnten argumentieren, dass es möglicherweise mehrere Kellner am Tisch gibt. Sie dürften sich jedoch in ihrer Verantwortung innerhalb von a unterscheiden Anwendungsfallwie in Rollennamen Headwaiter und Busboy gefunden. Selbst wenn ihre Verantwortlichkeiten identisch sind, würden sie dennoch als Kellner-1 und Kellner-2 oder als individuelle (benannte) Elemente eines Kellnervektors bezeichnet, wenn jemand beabsichtigt, Software für sie zu schreiben. Eine Rolle wie Headwawader wird also zur Kennung, zum Griff, durch den sich Objekte in a aufeinander beziehen Anwendungsfall.

DCI erkennt den Kellner eher als Objekt als beispielsweise als Zusammensetzung eines Mitarbeiterteils, eines Kellnerteils und eines Personteils. Das Objekt hat seine eigene Identität unabhängig von der Anwendungsfall; Dies ist die Datenfacette von DCI. Rollen sind aliased -Namen für ihre Objekte, aber niemals selbst getrennte Objekte. das würde verursachen Selbstschizophrenie. In diesem Sinne ist jeder Kellner ein Homo sapiens. Dies ist der rudimentäre Kellner, was der System ist-ist ein Teil. Das Objekt hat viele mögliche Identitäten, abhängig von der Anwendungsfall es ist an; Dies taucht in den Rollenidentitäten auf, die Teil der Interaktionsfacette von DCI sind. Dies sind der (normalerweise interessanter) What-the-System-DES-Teil. In DCI gibt es jedoch nur eine einzige Objekt Das trägt diese beiden Perspektiven zur Laufzeit. Diese Perspektiven können zum Codierungszeit unterschiedlich gruppiert werden. Der Code wird von der dominiert Anwendungsfall Struktur, die über die Objekte geht und auch Teil der Wechselwirkungsfacette von DCI ist.

DCI ermöglicht es einem Objekt, eine oder mehrere Rollen während a zu übernehmen Anwendungsfall Erlass. Mit anderen Worten, ein Objekt wird auf Rollenkennungen für jeweils wieder beschränkt Anwendungsfall Erlass. Diese Rollen schließen auf eine Schnittstelle, die als die bezeichnet wird Rollentyp. Jedes Objekt ist "neu" (im theatralischen Sinne) neu auf jedem Anwendungsfall. Obwohl eine Rolle nur an ein einzelnes Objekt gebunden ist, kann ein Objekt mehrere Rollen spielen. Zum Beispiel kann ein Hauptwarener an a beteiligt sein Anwendungsfall um alle Insassen des Restaurants während einer Brandinspektion zu zählen und die Rolle der Person sowie die Rolle des Headwaiters spielen. Das einzelne Objekt unterstützt das Verhalten beider Rollen, die für die Durchführung des Anwendungsfall.

Zusammenfassend lässt sich sagen, dass DCI -Architekturen durch die folgenden Eigenschaften charakterisiert werden:

• Das Datenmodell spiegelt eher die Domänenstruktur als die Partitionen seines Verhaltens wider.
• Objekte übernehmen dynamisch Rollen während Anwendungsfall Erlass;
• Jede Rolle von a Anwendungsfall wird durch ein Objekt gespielt, das vom Kontext zu Beginn der bestimmt ist Anwendungsfall Erlass;
• Das Netzwerk von Interaktionen zwischen den Rollen im Code (d. H. Zum Zeitpunkt der Codierungszeit) entspricht dem entsprechenden Netzwerk von Objekten zur Laufzeit.
• Diese Netzwerke werden potenziell auf jeden neu erstellt Anwendungsfall Erlass;
• Rollen kommen in und aus dem Spielraum mit Anwendungsfall Lebensdauer, aber Objekte, die diese Rollen spielen können Anwendungsfall Lebensdauer und kann möglicherweise viele Rollen über ihr eigenes Leben spielen.

Ausführungsmodell

DCI kann als als betrachtet werden ereignisgesteuerte Programmierung Paradigma, wo ein Ereignis (als menschliche Geste in a Model View Controller (MVC) Architektur) löst aus a Anwendungsfall. Das Anwendungsfall kann kurzlebig oder langlebig sein. Die Ereignisse werden genannt löst ausund sie werden in der gehandhabt Umgebung in das DCI eingebettet ist. Diese Umgebung kann der Controller einer herkömmlichen MVC-Architektur oder eines anderen Code auf Systemebene sein.

Der Auslöser bewirkt, dass die Umgebung a instanziiert Kontextobjekt. Die Art des Objekts wird nach der Art von ausgewählt Anwendungsfall Dies erfolgt basierend auf Informationen über den Auslöser, den Systemzustand oder beides. Beispielsweise kann eine Geldautomatin separate Kontextklassen für Geldtransfer, Abhebung, Einzahlung, Guthabenanfrage usw. haben. Sobald die Umgebung das Kontextobjekt instanziiert, ruft sie sich an Triggermethode Um den Anwendungsfall in Kraft zu setzen.

Wie oben beschrieben, bietet jeder Kontext einen Entwurfsumfang für die Rollen, die an der beteiligt sind Anwendungsfall Erlass. Es ist die Aufgabe des Kontextes, Objekte zuzuweisen, um diese Rollen zu spielen.

1. Der Kontext findet zuerst die Objekte, die daran teilnehmen sollen Anwendungsfall Erlass. Diese Objekte können sich überall in der Umgebung oder in einer Datenbank befinden oder im laufenden Fliegen erstellt. DCI schränkt diese Objekte nicht ein. Innerhalb eines Kontexts gibt es höchstens eine Instanz, die zu einem bestimmten Zeitpunkt eine bestimmte Rolle spielt.
2. Zweitens weist der Kontext ein einzelnes Objekt zu, um jede seiner Rollen zu spielen (obwohl ein einzelnes Objekt häufig in einem einzigen Kontext mehrere Rollen spielt). In stark dynamischen Sprachen (Ruby, Python) der Kontext Injektionen Die Rollenmethoden in das Objekt. In den meisten dynamischen Sprachen kann ein vorhandenes Objekt jederzeit aufgefordert werden, eine Rolle zu spielen (obwohl einige Objektrollenkombinationen natürlich keinen Sinn ergeben können; Unsinn-Kombinationen von Objekten und Rollen würden dazu führen Nachricht nicht verstanden Bei der Laufzeit, wenn die Rollenmethode aufgerufen wurde.) In statisch typisierten Sprachen (Scala, C ++) muss es eine vorherige Anordnung für das Objekt gegeben haben, um die Rollenmethoden zu unterstützen. Zum Beispiel erstellt Scala eine anonyme Klasse, die die rudimentäre Logik einer Domänenklasse mit dem kombiniert Anwendungsfall Logik der Merkmal verwendet, um eine Rolle zu implementieren; Rollen werden Domänenobjekten effektiv zugeordnet, wenn sie instanziiert werden.
3. Drittens ruft der Kontext eine Rollenmethode für das erste Objekt auf, das an der teilnehmen kann Anwendungsfall.
4. Von diesem Zeitpunkt an rufen die Rollen die Methoden des anderen zur Durchführung der Durchführung des anderen auf Anwendungsfall. Eine Rollenmethode kann eine Methode auf aufrufen selbst Was tatsächlich durch das Objekt behandelt wird, das derzeit die Rolle spielt. Auf diese Weise rufen Rollen die rudimentären Datenoperationen der Objekte auf, die sie derzeit zu diesem Zeitpunkt spielen.

Implementierung von DCI

DCI hängt von einem Entwurfsprozess ab, der sich trennt Anwendungsfälle Aus dem Datenmodell. Das Datenmodell basiert häufig auf einer informellen Domänenanalyse. Die Rollen, die das Modell der Systemfunktionalität des Endbenutzers charakterisieren, stammen aus dem Anwendungsfälle.

Implementierungstechniken unterscheiden sich in den Programmiersprachen. Was vielen Ansätzen gemeinsam ist, ist, dass Rollen durch Konstrukte wie Generika, Vorlagen, Klassen oder dargestellt werden Züge. Der Code für die grundlegende Domänenlogik wird separat implementiert, nachdem herkömmliche objektorientierte Praxis und am häufigsten Klassen verwendet werden. Der Code jeder Rolle wird in das Domain -Objekt eingefügt, das ihn während der spielt Anwendungsfall Erlass. Implementieren RollenEs wird normalerweise eine Methodeninjektion benötigt. Züge sind eine gemeinsame Programmiersprache -Technik zur Unterstützung der Methodeninjektion. Einige Sprachen, wie z. Scala, native Unterstützung für Züge, während andere Sprachen (z. B., Rubin und Python) Die Laufzeiteinspritzung von Methoden zulassen. Im JavaFür Anmerkungen werden vor den Kompiliertricks erforderlich, um DCI zu unterstützen.

Es gibt verschiedene Beispielimplementierungen: Smalltalk-Quietschen,^[2] C ++,^[3] C#,^[4] Rubin,^[5] JavaScript,^[6] Python,^[7] Qi4j (Java),^[8] Scala, Perl,^[9] und Php.^[10] und mehrere wurden zur fulloo.info -Website hinzugefügt, die von den Schöpfer von DCI gepflegt wurde.

Geschichte

DCI wurde von erfunden von Trygve Reenskaug, auch der Erfinder von MVC. Die derzeitige Formulierung von DCI ist hauptsächlich die Arbeit von Reenskaug und James O. Coplien.

DCI trat größtenteils als Auswachsen von Trygve Reenskaugs Arbeit zur rollenbasierten Modellierung auf.^[11] Trygve hatte seit langem erkannt, dass Rollen eine zentrale Rolle in der Art und Weise spielten, wie Programmierer über Objekte nachdenken, und dass der klassenbasierte Fortschritt der Programmiersprache Technologie viel von der Motivation genommen hat, über die Objekte in einem Programm nachzudenken. Das wiederum machte es schwierig, zum Programm zur Laufzeit zu argumentieren. Die Tatsache, dass objektorientierte Programmiersprachen nur Klassen boten, um die Programmlogik auszudrücken, ließen den Programmierer dem strukturellen Layout der Daten zum Abgrenzung des Verhaltens ausgestattet, was im Vergleich zu einem abschließlichen Verhalten an Rollengrenzen unnatürlich ist. Dies machte wiederum das Programmverhalten schwieriger zu argumentieren als in einem Verfahrensprogramm in Forran.

Trygve hielt es für wichtig, Programmstrukturen darüber zu erstellen, welche man argumentieren kann, und begann bereits 2000 mit der Geselligkeit dieser Ideen. Bis 2006 hatte er ein Arbeitsentwurfsmodell und seine Entdeckung 2008 von Schärlis Arbeit an Züge Vorausgesetzt, den Keystone, der natürliche Programmiersprachenausdruck dieser Ideen liefert. Er prototypisierte die Ideen in der Babyprogrammierumgebung, die in Quietschen geschrieben wurde. Jim Coplien schloss sich bei dieser Bemühungen um 2007 und bis Mitte 2008 einen Prototyp ein C ++. Steen Lehmann, Rickard Öberg und Niclas Hedhman beschleunigten diese Ideen an die Anpassung an Rubin und Java im nächsten Jahr mit dem Qi4j -Framework.^[1] Viele zusätzliche Sprachanpassungen folgten einer Sitzung auf der Jaoo-Konferenz in Dänemark im September 2008. 2010 wurde die Sprache Marvin von Rune Lund-Søltoft erstellt. Es war der erste Sprachgebäude mit native Unterstützung für DCI. Marvin war hauptsächlich als Beweis für das Konzept gedacht, um die Idee der "Injektion weniger DCI" zu präsentieren. Die meisten der vorherigen Implementierungen veränderten die Rollen -Spieler -Objekte auf eine Weise, die außerhalb des Kontextes sichtbar wäre. James Coplien schuf das Sprachtrygve basierend auf derselben Idee, die erste Sprache baute von Grund auf, um DCI zu unterstützen.

Unterschiedliche Ansätze zur Entwicklung der objektorientierten Programmierung, sowohl auf einer Sprache als auch in Bezug auf eine Sprache Muster Stufe stimmen mit DCI in verschiedenen Grad zu:

• Mischungen sind eine Möglichkeit, Code für eine spezifische Funktionalität des Systems in geschlossener Form zu verkörpern; Es gibt jedoch keinen konsistenten Mechanismus, um mehrere Mixins auf einer Einheit von a zu verknüpfen Anwendungsfall. Sie können eingesetzt werden, um das Konzept der Rolle in DCI umzusetzen, wenn auch nicht streng.
• Mehrfachversand war ein früher Versuch, einen Algorithmus von den Objekten, die an seiner Ausführung beteiligt waren, besser zu trennen, die durch die Trennung von DCI von gemeinsamen wiederkehrenden Algorithmen aus den Codefragmenten, die individuell zu einzelnen Objekten lokalisiert werden könnten, ergänzt werden können. DCI führt konzeptionell zu einer breiteren Wiederverwendung eines einzelnen Algorithmus in geschlossener Form in vielen Sätzen von Objekten mit weit verbreiteten heterogenen Typen. Das Kontextobjekt von DCI wirkt wie ein expliziter Intelligenz -Dispatcher, der zu den Versandmechanismen von Sprachen mit mehreren Versand analog ist.
• Echte objektorientierte Programmiersprachen wie Selbst Versuchen Sie, die Dichotomie zwischen den Domänen der klassischen Programmierung und der objektiven Ausführung aufzubrechen, was den Programmierern hilft, sich auf Laufzeitobjekte zu konzentrieren. DCI stellt das Wissen auf Code-Ebene über die Beziehungen zwischen ihnen in Kontexten und in den statischen Beziehungen zwischen Rollenmethoden wieder her.
• Abhängigkeitsspritze ist ein langjähriger Ansatz, um die Funktionalität eines Objekts zur Laufzeit zu ändern, indem es ihm erlaubt, einen Teil seiner Ausführung in ein externes Objekt zu "auszulagern", das nach Belieben wiederhergestellt werden kann. Die meisten Implementierungen^[die?] der Abhängigkeitsinjektion führen zu dem Selbstschizophrenie Problem, welche Implementierungen von DCI ordnungsgemäß ansprechen. Systeme wie ELMO verwenden diesen Ansatz, der zusätzliche Komplexität zur Lösung von Methodenmehrdeutigkeiten und doppelte Datenmitgliedernamen bringt.^{[12][Vollständiges Zitat benötigt]}
• Multi-Paradigmen-Design^[13] Versuche, das Verhalten und die Struktur durch das Verhalten zu einem prozeduralen Design und der strukturellen Komponente an Objekte zu trennen, ermöglichen es den freien Zugang zwischen ihnen gemäß den Designprinzipien von C ++. Der DCI -Ansatz kann sich verbessern, um die Beziehung zwischen den prozeduralen und strukturellen Teilen des Designs und dem allgemeinen Zusammenhalt auszudrücken.

Die Herausforderungen der objektorientierten Programmierung können auch durch die Behebung ihrer Probleme auf Paradigmenebene erfüllt werden.

• Aspekt-orientiertes Programmieren (AOP) ist vielleicht der engste historische Verhältnis zu DCI. Die meiste Verwendung von Aspekten ist eng mit der Programmierperspektive verbunden und erfordern eine starke Support für die Tools, um das Verhalten der Software für eine bestimmte Verhaltensweisen zu vermitteln Pointcut. Der Hauptunterschied besteht darin, dass in DCI die Struktur des Algorithmus primär ist und sich stark auf seine Isolation von Code außerhalb selbst konzentriert und die Code -Lesbarkeit verbessert. In AOP, die Pointcut und Rat Tragen Sie die gleiche Bedeutung und müssen zwar physisch unzusammenhängend sind, müssen zusammen verstanden werden, um den Code zu verstehen, da der Rat in der Invasive ist Pointcut. Während AOP eine administrative Gruppierung einer verwandten Sammlung einzelner lokaler Modifikationen liefert, die zusammen die Primärstruktur des Codes kennzeichnen, ist DCI ein semantischer Ausdruck eines Algorithmus mit erstklassiger Analyse, der vorhandene Objektmethoden aufgerufen wird. DCI kann als eine Möglichkeit angesehen werden, eine große zu nehmen Rat und zulassen, dass Teile davon in eine Reihe von regulierten injiziert werden Pointcuts.
• Rollenorientierte Programmierung bringt Ideen zusammen aus Aspekt-orientiertes Programmieren, konzeptionelle Modellierung ^[14] und mehr. Frühe Versuche (1991) definierten Rollen in unabhängiger Weise,^[15] Neuere Ansätze (2002 und weiter) konvergieren jedoch, dass die Rollen vom Kontext abhängen (auch "Teams" ^[16] oder "Institutionen" ^[17]). Bei rollenorientierten Programmierungen werden Rollen in Bezug auf eine intrinsische (oder Basis-) Entität definiert, die der Datenrollen-Dichotomie bei DCI entspricht. Das Konzept des Kontextes ist in beiden Ansätzen im Wesentlichen gleich. Beide Ansätze betonen die Interaktion zwischen einer Gruppe von Rollen.

Es können verschiedene Unterschiede identifiziert werden. Rollenorientierte Programmierung konzentriert sich darauf Programmiersprachen Wo der Schwerpunkt darauf liegt, die Ausdruckskraft einer Programmiersprache zu erhöhen und mehr Designs zu ermöglichen. Im Vergleich dazu hat DCI einen stärkeren Fokus auf die Methode Wie mentale Modelle erfasst werden sollten, wobei diese Methode teilweise als Einschränkungen für das, was als legales Design angesehen werden sollte, entsprechend DCI definiert werden sollte. Zum Beispiel: Autoren von DCI neigen dazu, eine gewisse Verwendung der Vererbung zu entmutigen (z. B. "Innerhalb von DCI erben Sie keine Rollen" ^[18]) während rollenorientierte Programmierung die Vererbung als zentrales Konzept der objektorientierten Programmierung umfasst (und sogar verbessert), was die freie Kombination mit anderen Konzepten unterstützt. DCI betont das Selbstschizophrenie sollte vermieden werden, während die rollenorientierte Programmierung behauptete, geteilte Objekte so zu verwalten, dass Schizophrenie kein Problem mehr war ^[19] Aber ein Moderator für flexiblere Designs. Eine spätere Arbeit der DCI-Autoren behauptet, dass Selbstschizophrenie ein Problem bei der rollenorientierten Programmierung unter Verwendung eines Gegenbeispiels nach einer modifizierten Implementierung von nach wie vor Dijkstra -Algorithmus.^[20] Daher opfert DCI die Vorteile der Vererbung für die vollständige Vermeidung seiner Mängel, während die rollenorientierte Programmierung einen Minderungsansatz verfolgt, was dem Ausgleich der Gefahren mit ihren beliebten Vorteilen Bedeutung gewährt.

Verweise

Externe Links

• Die DCI-Architektur: Eine neue Vision von objektorientiertem Programmieren von Trygve Reenskaug und James O. Coplien
• Die Google-Gruppe der Objektversorgung mit mehreren frühen Implementierungen von DCI durch Einzelpersonen
• Kontexte sind die neuen Objekte Von Rickard Öberg