(basically i think the article was written with some sort of anti-news-style approach, which was frustrating to me. i'd have liked it even more if it did the progressive refinement journalistic style instead.)

> What do you think of the ideas presented in this article?

The closest thing to writing something like this in Java is using Annotations right? You can inject some behavior with annotations but maybe not as elegantly as with a trait in Scala. It was a nice introduction to traits.

i respect the work here, so please don't take this quip as being too snarky, but... it kills me that it is as if functional programming never did and still doesn't exist! sheesh?!

Just a quick observation since this article tackles the problem of the user mental model vs. computer model:

Why does everyone insist on using Account Transfer as their primary example of system transactions?

Mentally the user may picture some sort of ACIDic transaction going on, but implementation-wise: no bank accounting system I ever came across uses transactions for this use case -

They all implement some variant of the Double Bookkeeping accounting principle; at best, you'll find a system transaction spanning the source account and some intermediary mother-of-all collection account (though not likely since most are of a different age).
The target account is most frequently not at the same bank, and even when, the Double Bookkeeping principle is still used. Even what the balance is on the account depends on what you're after, as the bank knows several.

In many ways, Banks implementation of the Account Transfer use-case is really closer to what is known as BASE: Basically Available, Soft State, Eventually Consistent; where end of day reconciliation ensures the consistency of the balance(s) on the account.

As an example Account Transfer may explain to developers the mental model behind how transactions are supposed to work, but it does not help them translate the mental model into a working computer model.

In the Scala example, the following is used to define a trait:


trait TransferMoneySourceAccount extends SourceAccount {
this: Account =>
...


Now, I'm not that familiar with that language, so can someone explain whether this binds the trait to the Account interface? And if so, in the Java world, why not make TransferMoneySourceAccount a proper class and inject an Account instance into it rather than worrying about trying to mixin the trait into SavingsAccount?

Thanks in advance.
Robert

I have great respect for the authors and I see the value in the style being promoted in DCI. I am struggling with the motivating example.

The authors were clear in demostrating that the traditional OO approach falls short in matching up to the user mental model (at least) in that an account ought not be smart enough to be resonsible for transactions and the like. But the example of extracting that behavior into a role that is then bound to the source account seems to fall sort as well.

Assigning the transfer role to the source account seems arbitrary to me. Why not assign it to the target? Why assign it to either account?

My mental model (admittedly I may be mental) is different from the example. I do have the two accounts and the notion of moving funds from on to the other. I diverge in that my mental model does not imagine the act of fund transfer being a role of either account. My model imagines that role belonging to the bank.

This mismatch keeps getting in the way of my willingness to appreciate DCI.

Nice article.
But I don't understand the example with the TransferMoneySourceAccount.
This algorithm operates on several parameters - the source account, the recipient, some anonymous transaction manager (having access to the database connection), a gui.
Each of these parameters is necessary to carry out TransferMoneySourceAccount::transferTo.

Later SavingsAccount inherits from TransferMoneyAccount - this makes the SavingsAccount a special parameter for the algorithm - it is accessible as "this" pointer after the most derived object is constructed.
What about the other parameters?
How can this design guarantee that recipient and gui are initialized properly after constructing the most derived object of TransferMoneySourceAccount?

What is the rationale for making the transfer money algorithm a class and not simply make that algorithm a free standing template function that operates on source account, destination account and gui (assuming that the transaction manager is still accessible as singleton).

The advantage about the heading to this article is you can immediately look at it and say... "User mental models vs Coupling and Cohesion" Ah! Whatever "Object" he is talking about is _not_ the Objects an Object Oriented compiler is talking about.

I'm not saying he is wrong, merely that he is not talking about compiler objects. OOP language "Objects" have some very hard mathematics driving the vital importance of...
* Encapsulation
* Information hiding
* Protection of Invariants.(Law of Demeter)
* Loose coupling and tight cohesion.
* LSP
..in "language level" Object Design.

http://www.artima.com/intv/goldilocks3.html

Screw with them, and no matter how nice and understandable and nicely fitting with user mental models your design is, you have defective and fragile code.

Having freed yourself from the mental coupling of compiler objects to whatever domain or analysis objects the article may be talking about.... we can continue to more reasoned discussion.

Of course, it would be nice if people could come up with different names for these different things, define them clearly and then stick to them.

Trouble is I think consultants thrive on the profits of confusion.

I find the example given to have a contrived feeling about it. There is nothing non-OO about a funds transfer. A funds transfer is a great class to have. More importantly, it is the sort of thing likely to be persisted to a database. While I agree with the idea that the accounts take on the "roles" of source and destination, it is quite likely that any account will contain protocol to implement either role and failing this will contain minimal protocol that will allow a wrapping adaptor to make fulfilling the role straight forward and obvious.

So much for examples. OTOH, I agree that there are certain interactions that defy good OO design practice. Specifically, business rules and constraints. These rules typically capture interactions which defy all reasonable ideas of locality of reference (thank you - legislators). This is where pattern matching rules engines like ObjectiveCLIPS (http::/objectiveclips.com), JESS, CLIPS, Rete++, and similar products can save the day.

>Your design really ought to allow the details to vary, while
>keeping the semantics the same - without requiring subtyping
>for different products.

Sure, hopefully the later articles will have better examples than bank accounts.

>The problem is, both roles and the 'actors' playing them are
>derived from same ancestor, creating two parallel
>inheritance hierarchies (this makes sense because a
>Source_Account IS an Account and Savings_Account IS an
>Account too).

But a Source_Account isn't really a "thing" like an Account is, it's a way to use a "thing". So Savings_Account IS an Account (inherits from), but Source_Account is a WAY TO USE an Account (contains pointer to).

I'm having a significant problem seeing what's different in this approach than the approach advocated by, among others, Fowler and Cockburn(1). They advocate a separate layer between the GUI and the domain - this has been called the Application or the Process or Procedure layer by different authors.

To take the example of a funds transfer between accounts: the domain would include the various kinds of account objects as well as a FundsTransfer object. The latter object is needed because it's the transaction log, the source for the bank statement and the line entry in the bank's accounts.

When the logged-in customer presses the "transfer money between accounts" button, the ATM GUI creates the ATMFundsTransfer object. The ATMFundsTransfer object then creates the domain FundsTransfer object with the amount, the source account number and the recipient account number, and it interprets the result (done or insufficient funds) back to the GUI.

This matches the mental model (or at least my mental model) of how a bank transaction is normally done.

John Roth

(1) http://alistair.cockburn.us/Hexagonal+architecture

I like the idea of clearly separating complex multi-object behaviour from base domain classes.

However the assignment of transferTo() to a Source Account seem arbitrary to me; it belongs to the Context instead. And why the Context could not be a simple procedure instead of an object? Like

void Transfer_Money (Source_Account src, 
                     Destination_Account dst, 
                     Money amount);

Next, why the Source_Account could not be simply derived privately from 'dumb' Account? Like

class Source_Account : private Account {
    void Withdraw (Money amount) { ... }
};

Bill, James and Tryggve.

> The Qi4J environment (Richard Öberg and Steen Lehmann)
> is pushing forward the ability to express traits in a
> Java environment.

I would appreciate if credit is not given incorrectly. Steen is an all-time good guy, but his involvement in Qi4j is non-existent at best. Rickard and myself are the founders, and there is a team of ~5-10 people who work on the codebase to varying degree.

Posted a real world example of DCI with Scala on

http://sadekdrobi.com/2009/06/10/dci-in-real-world-domain-context-and-interaction-with-scala-in-a-real-world-project

It is open to any improvements, suggesions or critics.

I am not sure that the DCI Architecture is the new vision of OOP. As I pointed out to Trygve Reenskaug in the personal e-mail, MVC is the concept that was used not only for OOP, but in non-object oriented environments and languages. It seems to me that DCI is just a sort of renaming things that were intriduced by the professor 3 decades ago. It resembles the Microsoft practice of inventing new terms for the same subject. I do not think that DCI can simplify any development efforts or drive to a better framework or application.

If they need such a long article to explain what the DCI architecture is, then I am sure it will not work in reality.

Things that truly work are truly simple.

@MVC is about people and their mental models—not the Observer pattern

This is the most pretentious, long-winded, non-scientific article written by academics imaginable.

"Hey, you foolish practitioners, you are ignoring the user."

First off, their real world example is AWFUL and they're discredited on that basis alone. And I quote:

@2. System displays valid accounts

WHAT? Are you seriously going to put a System class in your problem domain analysis classes? That will adversely affect the gross application structure, which is SUPPOSED to directly reflect the problem domain. You are sharing server-side concerns with the client. Why stress your network that much? This example basically mimics many awful ATM controller software examples in various books alleging to teach OOA.

I will stick with Allen Holub's brilliant criticism of MVC: It is fundamentally not OO, because of Controllers. Object-oriented programs should RENDER THEMSELVES. Objects should be able to render themselves. Not being able to meet this constraint is an obvious code smell that you should clean up. This code smell is typified by frameworks like Struts.

This is actually why understanding how real-time OO engineers apply OO can be so helpful to enterprise programmers. Once you start thinking in real-time terms, chatty protocols become obviously unacceptable. The fact they deal with subsequences at the application protocol level is an analysis smell: You're coding low-level details at the highest layer of your architecture, which will make it impossible to stabilize design, forcing recompilation. Today, most MVC approaches use IoC containers and pluggable architectures to try to skip as much recompilation as possible, but mentally they're still recompiling.

My designs are pretty stable, although I refuse to call them MVC, because of the use of Controllers. My objects render themselves - they don't expose implementation details simply so that a delegate can render for them. And you know what? I rarely recompile these days.

The much bigger question is how to build OO systems based on REACTIVE MODELS. Reactivity gives you a direct mental model for any user.

The OO Problem

From a high level DCI et al is an effort to "fix" what is broken in the OO model from an OO perspective.

The brokenness manifests itself with standard OO Analysis and Design. Parse the domain into classes, assign responsibilities to said classes ,and execute Use Cases via collaboration of runtime object instances of said classes.

The failure is the inability to pigeon-hole a clear unit of capability/responsibility solely to a single class. It all becomes a forced, shoe horning of capabilities into classes, the opposite, a thin scattering across classes losing all cohesiveness. OO says you _have_ to "put it" somewhere.

And your told if you can't figure out where to put it, you're OO chops are just not up to snuff or your OO model is flawed. Throw it out and start over until you can assign each capability/responsibility to its appropriate OO owner. The fact that this is not possible is ignored by OO.

One camp says the problem is your classes are just too domain anemic, that Order class needs to be beefed up for example. But it becomes a blackhole. More capability, entails and entrains more capability. The Order class soon becomes the Ordering class, a massive God Object that IS the program.

At which point the other camp chimes in no, no, no, "do one thing and one thing only" in your classes. Then all your devouring blackhole God objects go Nova, exploding into a scintilla of ever more anaemic single purpose classes., devolving towards simple state wrappers and manipulators, increasingly orphaning the "do stuff" aspects of your program with nowhere to "put" it.

As all the Noun classes rapidly devolve into simple Data Encapsulators a myriad of -e/or classes explode onto the scene to stitch things together. These are the artificial Class constructs sprung straight from the forehead to act as places to attach all the orphaned "do stuff" code.

The Transact-or, the Book-er, the Price-r, the Submit-or, the ... Do'er. But it's all wrong, wrong, wrong, it ain't OO, and you HAVE to be OO. So you take all those zillions of teeny tiny classes do'er and state wrappers that lack any sort of coherence and start merging and combining things back into Nouns classes. Carefully assigning capabilities strictly and solely to each one. Blackholes God classes re-emerge sucking in responsibilities, demanding attachment, until ...

While BigBang followed by Collapse and re-Bang in an endless cycle may be a fine way to run a universe, it is not necessarily so for running the design of a program.

Fixing OO Can't Be Done Via OO

I think the "ideas" to fix OO are and have been out there for quite awhile. The failure is the repeated attempts to apply the fixes in the context of OO in tortured OO terms.

A entirely new and different vocabulary is necessary. Instead of trying to stretch OO concept semantics to "bend" in new concepts why not just properly label the new concepts and retain OO terms and concepts for OO.

For example, in DCI, objects tend to degenerate into "dumb" simplistic state encapsulators barely smart enough to manipulate their enclosed state. The canonical DCI Account classes encapsulate an amount value and token manipulator methods of this value. Yet is is still discussed as an OO class with OO instances. But it's not. Its no longer a robust domain driven Account stuffed with transactive capability for example. Its just a state wrapper and manipulator. Its closer to a simple structure with associated procedures with an implicit self parameter than full-blown OO object.

The point of all the above is to say that fixing the conceptual flaws of OO-ness by constraining solutions to be OO-centric in nature does not appear to be working very well. The solutions appear well known but fail to translate and for the life of me I don't understand why the translation is necessary! OO must be subsumed by a new solution; it cannot be the solution, only an aspect of it.

To be clear I certainly don't know enough to state the solution. What I am saying is it appears some really smart people appear to know the answers but fail to materialize them in translation. The self imposed OO-only constraints completely obstuficate what were originally rather straight forward solutions.

Attempts to demonstrate new multiparadigm higher level design approaches that sit above OO design become a morass with repeated attempts to reifiy the solutions within OO boundaries.

Watch for example the Account with Funds Transfer problem degenerate into exercises in tortured C++ templates or pushing anaemic, kindergarten Java to do things via ever more clever contortions.

What Must Be Done

Stop trying to shoehorn multiparadigm solutions within a legacy context OO paradigm context. Stop defining solution paradigms a top of ancient languages such as C++, Java or SmallTalk. Total waste of time. They cannot be fixed. Enough with exotic, boilerplate, effusive "Patterns" over these substrates. We need a better substrate.

OO must be subsumed or at minimum become a peer paradigm NOT the central tenant. Why continue to discuss a new paradigm such as DCI in OO terms within an OO constrained language, when a priori your objects are not objects, often just dumb data manipulators, and just-in-time role casting is necessary?

The answer is obviously a multi-paradigm / hybrid one. I'd go as far to claim at a minimum one which combines Functional with OO.

One must start with a multi paradigm / hybrid language to properly demonstrate new design and implementation solutions. Lets use Scala for the rest of the discussion. Why? Its multiparadigm (OO, Functional, Actor, Pattern, Algebraic) in design AND clean enough that there is a good chance missing paradigms could be added cleanly as smooth extensions of the language or properly as libraries.

For the hell of, imagine if the current semantics of Scala was _not_ modified one iota, however the following term syntax aliasing was allowed.


object -> module
package object -> package module
trait -> trait,
class -> structure.


To get a gist of the impact of these simple term substitutions let's examine a couple of them.

Module over object encourages people to "think" conceptually different. Its a gathering spot for those procedural, algorithmic things. It is a place where "functional" things can be defined cleanly. These is no dissonance in concieving the below in a "module". But it's a mental hurdle to view it both as a singleton "object", and as the natural container for such constructs.


type T = ...

val c = ...

val f[A,B,C]: (g: (A, B) => C) (x: A, y: B) => g (y, x)
val h (x: Int, ..) => ...

def k (..) = ...




It is the proper place in Scala land of course, but it seems forced. Of course the Scala folks know this. So why Object and not Module. Because we keep trying to defined new concepts as tortured OO concepts otherwise the Java folks won't grok it. People don't know what a Module is anymore therefore the most intuitive way to add modules conceptually is as singleton object.


Aside: Imagine, giving a talk to COBOL, VB, PL1, RPG, PLSQL and Java developers, its the folks with only the "modern OO" language experience you have to slow down for to explain what modules, procedures and functions are. Ironic.

Object implies Class instance and hence a sort of domain mapping (for me) and the reification of some domain "thing". But it's simply a cohesive grouping of procedural code, functions and algorithms that "do stuff". Where is the "object" I ask you? Sure one can hand wave and claim scala Object is isomorphic to a Module, but damn it it's a module first and a clever means singleton object construction second.

Class -> Struct. (SML structure, not C) Again the idea here is to move away from the OO relentless domain mapping of objects and things and allow one to think in a guilt free manner of constructions whose primary purpose is to encapsulate and manipulate state without OO burden.

I want to be guilt free to think of these things as simply encapsulated data, with associated functions with an implicit self parameter without a receiving a citation from the OO police for an Anaemic Object violation.

By simply aliasing 5 or 6 key terms in the Scala language, without changing any of the semantics of the language, one gets a "whole" new language in the sense that the "way" a single individual would write a program to solve a problem would radically shift.

Same problem, same programmer, same language. Alias five terms and one would gets a more functional code base with appropriate and prevalent state encapsulation. Same semantics just different labelling, say Structures/Instances instead of Classes/Objects.

Leave the current syntax labelling in place one would get a OO centric code base with modest migration of procedure code and algo out of Classes. It all depends on how much the developer can soar above the OOness of the Scala's bias to use non-OO paradigm constructions with peer OO constructions to solve the problem.

One variation of Scala supports DCI and other solutions with less dissonance, the other implies a straining to achieve DCI, a continued uphill struggle to break free beyond just OO in the solution space. In less capable languages such as C++ or Java the strain becomes an all out war against the language limitations itself.

DCI's "how to implement" is too complicated , traits is not new thing, just like AOP's static weaving.

Domain Events is another way:

Account owner send event to his account, and the source account do his balance, after that it will send domain events to target account, let target account update its balance.

this is EDA architecture.

see how it do in java with entity(data model) Injection:
http://www.slideshare.net/banq/jdonframework-2734177

Jim Coplien's talk "The DCI Architecture: Supporting the Agile Agenda" recorded at Øredev 2009, Sweden:

http://vimeo.com/8235574

In the "Other bits" section there is statement about business rules and how DCI does not provide a convenient way to capture them. You can look at the book "Streamlined Object Modeling" by Nicola, et al and see if that might work. Since the patterns are based on the relationships between objects, and not the objects themselves, mixing in the required behavior might be straightforward.

Mark

By the way, Jim, don't take my rant personally. However, I'm trying to get you to think clearly.

If you are going to present a solution to something, you actually need to describe:

(1) what the problem is
(2) what contributions you can make
(3) experimental results, including prototypes, field studies and project data

More importantly, practitioners have a hard time relating to abstract concepts when there is no connection to a real world problem they have.

By presenting the strawman that "programmers just don't get MVC, but it works", you're basically saying all we really need to do is use something correctly. At which point, I'm wondering why the rest of the article isn't focused on teaching it correctly.

Instead, the article diverges and becomes a sermon about how we've all overlooked some practically fundamental architectural concepts -- "traits", if you will.

Actually, in my 14 years as a programmer, my biggest benefit to an architecture that includes a GUI is what I call the designer-developer facade. Pretty much every system I've seen others build gets this facade incorrect, because once you have to dynamically vary the UI -- for any reason -- you take the design tools out of the designers hands and force him/her to describe the interaction effects to a developer. This doubles resources, and frequently the developer is untrained in how to program complex reactive systems where arbitrary events can occur. As a result, copious bugs pour in. The end result is frequently event handlers with ad-hoc case statements.

There are a few exceptions. For instance, the best selling video games Crash Bandicoot 1 through 3 were architected by one of the top 5 Lisp programmers in the world: Andy Gavin. After several iterations, it was stratified into two main subsystems: a Lisp language for game engine subsystem programmers and a DSL for artists and scene designers. More recently, two members from that 9 person video game company (including cofounder Jason Rubin) started a dotCOM called Flektor, which embodied much of the same principles.

So it is possible to create a designer-developer facade.

But you fail to tell me how to do this (I know how, but just follow me).

And, actually, your traits don't tell me anything about temporal constructs, which is a fundamental element of reactive systems and composing a realistic user's mental model.

Your traits also give the appearance that you're creating mini-classes to provide ad-hoc case statements. The only difference between your classes and an ad-hoc case statement is that you've got type-checking; you've added a little bit of structure. In fact, Odersky recognizes this by providing a switch statement on steroids that can do structural pattern matching. However, you don't explain why that incremental structure improves code clarity, testability or conceptual design.

You also neglect that a parts-centered object model gives you stronger compile-time type checking for what you are trying to accomplish than a specialization-centered object model, hence why you mentioned trying to avoid traditional class inheritance. However, all you do is provide extension methods with a friendship relationship to a class. That's not an awful thing, and the C++ Client/Attorney idiom can be used to good effect, but it is an implementation detail far apart from the architectural level that MVC addresses. It's also far apart from the level of abstraction of considering a system with an architectural constraint of a *pure* developer-designer facade.

Pure abstractions are much harder to design than pure functions, but they give us the ESSENCE Brooks' talks about. Yet, should these abstractions change at the architectural level, they are changing to reflect real world realities. If the roles of designers and developers change, then they will likely change in ways that allow each person at opposite ends of the role the least amount of grief possible. For that reason, you stabilize design around that architectural constraint, not MVC or DCI.

I read the article with great interest and I salute the authors for taking the time to write it. However, from the article:

"Object-oriented programming languages traditionally afford no way to capture collaborations between objects"

to which I respond that a bad workman blames his tools!

It is your choice to create and use objects for whatever you want to, including capturing the collaborations between objects. In fact, this is the heart of OO. When you model an object and have it interact with another you can choose to model that interaction as another object with a simply method invocation to carry out the interaction, or you can create no object and call a series of methods. A lot of this is captured in the OO principle Tell Don't Ask but most people just Ask, ignoring the benefits of Tell all together.

For example:

address.to_string() <- simplistic - why do you need a string?
address.printOn(medium) <- OO, capturing the interaction. You can also take this further with an object that represents the process of taking an address and putting it onto medium.

I wrote a lot about this in several posts on my blog about a technique I call East Oriented - http://jamesladdcode.com/?p=12

We have failed OO, it has not failed us.

- James.