DCIData Context Interaction:Re-thinking the foundation of object orientation and of programming

DCI: Introduction• Invented by Trygve Reenskaug (MVC)• Refined by James O. Coplien• The paradigm separates the domain model (data) from use cases (context) and

roles that objects play (interaction). • Complementary to model–view–controller (MVC).

Objectives:• Improve the of object-oriented code readability• System behavior gains first-class status;• To cleanly separate code for rapidly changing system behavior (what the system

does) from code for slowly changing domain knowledge (what the system is)• Help software developers reason about system-level state and behavior

instead of only object state and behavior;• Support an object style of thinking that is close to peoples' mental models,

rather than the class style of thinking that overshadowed object thinking early in the history of object-oriented programming languages.

From procedural to object orientation• 1960 – 1970 Procedure Orientation: Succes1. Data-centric architecture for separation of state and behavior2. Application design with functional decomposition3. Textual code flow reflects process flow4. Peer review of code chunks to get it right the first time5. Testing as a “no blunder” confirmation

• 1971 – 1995 Class Orientation: Collapse1. Class-centric architecture with ecapsulated state and behavior2. System design with functional fragmentation3. Fragmented code NOT show process flow4. No Chunks: no peer review5. Code correctness can only be explored by tests

Decomposition vs Fragmentation

Big Algorithm split in several little chunks

Where is the algo?

All is about objects• Class oriented programming• OO fails to capture behavior• No obvious “place” for interaction to live• Failure to capture the user mental model• Algorithms: from procedural approach to distributed

algorithms (coupling and cohesion)

Class oriented programming• Nouns are objects and verbs are methods• Objects are supposed to be stable• Behavior changes frequently• Artificial solution: using inheritance to express "programming

by difference" or "programming by extension”• Open-closed principle: the vernacular of the design• Liskov Substitution Principle• Favor composition over inheritance (16)• Domain classes should be dumb!? An anemic domain model

approach?

Transaction Scripts and Service Layer

• Poor domain model• All the usecase and domain logic into

the Transaction Script• Duplicated code

• Rich domain model• Service layer as a facade• Uses case centric behavior fails to fit

• Rich domain model• Thick Service layer • Unable to reuse code in other applications• Cross Services code duplication

• Transaction Scripts• No Domain Model

• Thin/No Service Layer• Domain Model

• Thick Service Layer• Domain Model

Users and programmers mental models

System Operations executed by Contexts

Roles and DCI• Combining Structure and

Algorithm in an Class

• Combining Structure and Algorithm in an Object

DCI and User Mental Model

End User and Programmer reconciliation

MVC• Information is a key

element of the end user mental model

• Not a set of Observers• MVC-U is all about

making connections between computer data and stuff in the end user's head

• Capture well what the system is but NOT what the system does.

DCI and MVC• Mapping roles to Objects• Controller works with

Contexts• One context per Use Case

DCI components:• The data, that live in the

domain objects that are rooted in domain classes;

• The context that brings live objects into their positions in a scenario, on demand;

• The interactions, that describe end-user algorithms in terms of the roles, both of which can be found in end users' heads.

From procedural to object orientation• 1960 – 1970 Procedure Orientation: Succes1. Data-centric architecture for separation of state

and behavior2. Application design with functional

decomposition3. Textual code flow reflects process flow4. Peer review of code chunks to get it right the

first time5. Testing as a “no blunder” confirmation

• 1971 – 1995 Class Orientation: Collapse1. Class-centric architecture with ecapsulated

state and behavior2. System design with functional fragmentation3. Fragmented code NOT show process flow4. No Chunks: no peer review5. Code correctness can only be explored by

tests

• 2000 True Object Orientation: A new Beginnig1. DCI architecture for separation of system stae and behavior2. Functional separation in Context with Roles3. Methodful roles show process flow4. Peer review of code chunks to get it right the first time5. Testing as a “no blunder” confirmation

Templates Traits Mixins

. . . . template <class ConcreteAccountType> class TransferMoneySourceAccount {public: void transferTo(Currency amount) { beginTransaction(); if (self()->availableBalance() < amount) { . . . . }

. . . . class SavingsAccount: public Account, public TransferMoneySourceAccount<SavingsAccount> { public: void decreaseBalance(Currency amount) { . . . . } } . . . .

• C++

Templates Traits Mixins

trait TransferMoneySourceAccount extends SourceAccount { this: Account =>

// This code is reviewable and testable! def transferTo(amount: Currency) { beginTransaction() if (availableBalance < amount) {

. . . . }

} . . . . val source = new SavingsAccount with TransferMoneySourceAccount val destination = new CheckingAccount with TransferMoneyDestinationAccount . . . .

• Scala Trait