Haxe dci-presentation by Andreas SÖDERLUND

DCI
- How to get ahead in software architecture

About me
Andreas Söderlund
Independent consultant in northern Sweden.
Worked on larger web systems and applications for 10-15 years, specializing in
system integration and architecture.
● E-commerce
● Banking
● Large-scale social platforms.
Haxe projects
Haxigniter, ufront, erazor, unject, umock, Haxedci, HaxeContracts

FORTRAN - IBM Mathematical Formula Translating System
COBOL - COmmon Business-Oriented Language
The roots of programming
"Formula translating", "Business-oriented"
Mapping from one language to another

"An explanation of someone's thought
process about how something works in
the real world."
Mental Models
"Lift the receiver and call the person you
want to reach by turning the circular
wheel."
Object terminology (receiver, wheel)
- with a function (call a person)
- based on a form (the phone).

"I need a container to get the wasp out."
Form & Function
The form enables the function

Mental Model Matching
When the mental model matches, the objects you control becomes an
extension of your mind.
It feels like you are directly manipulating the system.

Mental Model Matching...?
When the mental model mismatches, you lose control.
The programmers mental model mismatched the users.
Note: All unit tests passed in the software above!

The System
Objects with form... ...that can have different types of function
Mental models: Thought processes about the behavior of the above
Maybe all this can be called a system.
And the form of the system, its architecture?
"A set of interacting components forming an integrated whole"

Making a digital ordering
system for restaurants.
Designing a System
There must be a register with name and
birthdate of all employees.
Use when:
- Serving food
- Cooking food
- Customer pays bill
- Manager pays salary
class Employee
{
public var name : String;
public var birth : Date;
}
class Waiter extends Employee
{
}
class Chef extends Employee
{
}
class Manager extends Employee
{
}

class Employee
{
}
{
}
{
}
{
}
"The waiter walks up to the guests and
shows them the menu. He takes the
order and passes it on to the chef. The
chef cooks the food, which is brought
out to the guests by the waiter.
After the meal the waiter brings the bill
to the guests, and collects the
payment."
The mental model of serving guests at
a Restaurant:
Designing a System

Part I
Inheritance
The Manager can also be a Chef and Waiter, if
the restaurant is small.
class Employee
{
public function serveFood() {}
public function cookFood() {}
public function bringBill() {}
}
{
}
{
}
{
public function paySalaries() {}
}
I refuse to
deal with
customers!
I'm a great
waiter, but I
can't cook!

Part I.5: Multiple
Inheritance
The Manager can also be a Chef and Waiter, if
the restaurant is small.
class Employee
{
}
{
public function serveFood() {}
}
{
}
{
}
class ChefManager extends Chef extends Manager
{
}
class WaiterManager extends Waiter extends Manager
{
}
Not all Managers are both Chefs and Waiters of
course!
...what if even more employee types are
added?
...and how to instantiate this hierarchy?

Part II
Interfaces
class Employee
{
}
interface IChef
{
function cookFood() : Food;
}
interface IWait
{
function serveFood(f : Food) : Void;
function bringBill() : Money;
}
interface IManage
{
function paySalaries() : Void;
}
class Chef extends Employee implements IChef
{
}
class Waiter extends Employee implements IWait
{
public function serveFood(f : Food) {}
}
class Manager extends Employee implements IManage
{
}
class ChefManager extends Manager implements IChef
{
}
class WaiterManager extends Manager ...
...
This is a beautiful architecture:
This code doesn’t have a beautiful form and
architecture.

Part II
Interfaces
class Employee
{
}
interface IChef
{
}
interface IWait
{
}
interface IManage
{
}
{
}
{
}
{
}
{
}
...
The code looks more like this:

Part II
Interfaces
The system form is not a representation of
the user mental model anymore (maybe
somewhere deep within), it's more and more
about engineering.
Want some Design Patterns with that?
- Abstract Factory
- Adapter
- Command
- Decorator
- Flyweight
- Memento
- Strategy
- Visitor
- ...
class Employee
{
}
interface IChef
{
}
interface IWait
{
}
interface IManage
{
}
{
}
{
}
{
}
{
}
...

Part II
Interfaces
class Employee
{
}
interface IChef
{
}
interface IWait
{
}
interface IManage
{
}
{
}
{
}
{
}
{
}
...
Want some Patterns with that?
- Abstract Factory
- Adapter
- Command
- Decorator
- Flyweight
- Lock
- Memento
- Strategy
- Visitor
- ...
Design patterns can be useful as implementation, but not as a user mental model and architecture.
However, there are patterns that are used to align a user mental model with the computer, like MVC.
This is an "indoor session initializer" because
there is a session that counts the number of bla
bla… (Nerd forcing mental model onto user)

Part III
Services
class Employee
{
}
interface IChefService
{
function cookFood(Employee e) : Food;
}
class ChefService implements IChefService
{
public Food cookFood(Employee e) { … }
}
// The program
static function main()
{
var chefService = Services.Get(IChefService);
var chef = Employee.Get(2);
chefService.cookFood(chef);
}
Object model mismatch. We move from “who
does what” to “what happens”. Too imperative
and all-knowing.
Information is abstracted away through
interfaces.

Part IV
DCI
Data, Context, Interaction

Inventors of DCI
Trygve Reenskaug
Inventor of MVC
Wrote CAD-software in the 60’s
Professor Emeritus, Oslo
James “Cope” Coplien
Author of several influential C++ books
Created most cited patent in software history
Chair CS 2003-2004, Brussels
Patterns, Scrum, Agile, Lean...

class Employee
{
}
● Chef - Cook food
● Waiter - Serve food, bring the bill
● Manager - Pay salary
Data
Function

class Employee
{
}
Data
Function
public function cookFood()
public function serveFood()
public function bringBill()
public function paySalaries()
Waiter
Waiter
Manager
Chef
If an Employee object
could attach the
cookFood() method...
then it could be a
Chef!
We cannot do it in classes (we tried in part I-
III), so it seems like it must be a more
dynamic operation.

class Employee
{
}
Data
Function
Waiter
Waiter
Manager
Chef
Employee
object
public function
cookFood()
This Employee object can now play the Role of a Chef!

class Employee
{
}
Data Function
Waiter
Waiter
Manager
Chef
Employee
object
public function
cookFood()
Now
a Chef
... a little later in
the program...
Same
Employee
object
{}
Later
a Manager
public function
paySalaries()

A Role is only relevant in a specific Context.
Roles and Contexts
A Mental Model can be represented as a Context!
Chef.cookFood()
vs.
Chef.cookFood()

Part IV
DCI
// Data (Form)
class Employee
{
}
payment."
The Context (Mental Model) of serving
guests at a Restaurant:

Part IV
DCI
// Data (Form)
class Employee
{
}
Remember from part I-III:
The methods cannot go in the data
class, they should be attached by some
means.
Where to put the methods, the
functionality?

Part IV
DCI
// Data (Form)
class Employee
{
}
// Context (Mental Model)
class ServeGuests implements haxedci.Context
{
@role var waiter = {}
@role var guests = {}
@role var chef = {}
}
payment."

Guests ChefWaiter
guestsArriving()
selectFrom(menu)
takeOrder(order)
cook(order)
serve(food)
Part IV
DCI
"The waiter walks up to the guests and shows them the menu. He takes the order and passes it on
to the chef. The chef cooks the food, which is brought out to the guests by the waiter.

Part IV
DCI
The current “OO” way of
creating object communication:
Passing messages between
objects wherever and whenever
it is needed.
- Too chaotic
- No separation of data and behavior
- Can only see one object at a time
- Reasoning about system behavior
and functionality is very hard.
- Prevents object communication
- Creates a complex all-knowing
algorithm
- Basically a step back to Pascal
and Fortran.
Procedural thinking,
implemented as the
Mediator pattern.
- State and behavior is distributed
among the objects
- Creates a network of
collaborating objects
- We can reason about system
behavior at runtime!
DCI: A middle road,
distributed logic
under full control,
encapsulated in a
Context

Guests ChefWaiter
guestsArriving()
selectFrom(menu)
takeOrder(order)
cook(order)
serve(food)
Part IV
DCI
"The waiter walks up to the guests and shows them the menu. He takes the order and passes it on
to the chef. The chef cooks the food, which is brought out to the guests by the waiter.
Runtime
interaction!

Part IV
DCI
// Data (Form)
class Employee
{
}
{
@role var waiter = {}
@role var guests = {}
@role var chef = {}
public function new(employeeWaiter,
employeeChef,
guestList)
{
this.waiter = employeeWaiter;
this.chef = employeeChef;
this.guests = guestList;
}
payment."
// System operation (Event)
public function guestsArriving()
{
waiter.guestsArriving();
}
}

Part IV
DCI
{
@role var waiter =
{
function guestsArriving() : Void
{
var menu = “1: Roast beef. 2: ...”;
guests.selectFrom(menu);
}
}
}
payment."

Part IV
DCI
{
@role var waiter =
{
{
}
}
payment."
guests at a Restaurant:@role var guests =
{
function selectFrom(menu) : Void
{
Sys.println(menu);
order = Sys.stdin().readLine();
waiter.takeOrder(order);
}
}
}

Part IV
DCI
{
@role var waiter =
{
{
}
function takeOrder(order) : Void
{
Sys.println("Thank you.");
chef.cook(order);
}
}
payment."
@role var guests =
{
function selectFrom(menu) : Void
{
Sys.println(menu);
var order = Sys.stdin().readLine();
waiter.takeOrder(order);
}
}
}

Part IV
DCI
// Data (Form)
class Employee
{
}
{
public function new(...)
{
this.waiter = employeeWaiter;
this.guests = listGuests;
this.chef = employeeChef;
}
payment."
public function guestsArriving()
{
}
public function guestsPaying()
{
waiter.bringBill();
}
}

If "self" in the role doesn't reference
the object itself, it's not DCI.
// Data (Form)
class Employee
{
}
// Role
@role var waiter =
{
// RoleInterface
var roleInterface : {
var name : String;
}
// RoleMethods
{
Sys.println(self.name);
context.guests.selectFrom(menu);
}
...
}
Part IV
DCI
A DCI Role has a RoleInterface and
RoleMethods. The Role is private to its
Context.
The execution model for DCI is
different, adding new keywords: role
and context.
Object identity MUST be preserved!
(not equality, identity!)
The Employee Data (Form)
matches the RoleInterface, so
it can play the waiter Role.
Form matches the
RoleInterface for the
Role “container” in
the Context
“Remove Insect”

So what is DCI?
// Data (Form)
class Employee
{
}
// Context (Mental model/Use case/Algorithm)
{
@role var waiter =
{
// RoleInterface (Compatible Form)
var name : String;
}
// RoleMethods (Function)
{
var menu = new List<String>();
// Interaction (System behavior)
}
}
// System operation (Events)
public function guestsArriving() : Void
{
}
}
A method of reflecting user mental
models in code.
A way of separating what the system IS
(Data, slowly changing) from what it DOES
(Function, quickly changing).
Allows reasoning about the correctness
of system functionality, not just
class/method functionality. We can
observe exactly what happens at
runtime. No Polymorphism.
Behavior is put back within the
boundaries of a human mental model,
not spread across classes, services,
patterns...

So what is DCI?
class Employee
{
}
{
@role var waiter =
{
var name : String;
}
{
var menu = new List<String>();
}
}
public function guestsArriving() : Void
{
}
}
A method of reflecting user mental
models in code.
A way of separating what the system IS
(Data, slowly changing) from what it DOES
(Function, quickly changing).
Allows reasoning about the correctness
of system functionality, not just
class/method functionality. We can
observe exactly what happens at
runtime. No Polymorphism.
Behavior is put back within the
boundaries of a human mental model,
not spread across classes, services,
patterns...

Questions?
DCI Headquarters:
http://fulloo.info
Google “haxedci”

Thank you!
andreas@ivento.se
github.com/ciscoheat
google “haxedci”

Haxe dci-presentation by Andreas SÖDERLUND

More Related Content

Viewers also liked (15)

Similar to Haxe dci-presentation by Andreas SÖDERLUND (20)

More from Grégory PARODI (9)

Recently uploaded (20)

Haxe dci-presentation by Andreas SÖDERLUND