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).

John Carter,
Thanks for your very enlightening comment:

@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.

This is exactly the problem. No, we are NOT talking about what you call "compiler ojects", we are talking about runtime objects. The term "object oriented compiler" is misleading IMO. It should be called a "class oriented compiler". An object has identity, state, and behavior. The class abstraction hides identity and only describes the other two properties.

To me, an object is a runtime phenomenon that has a unique and immutable identity. The problem with class orientation as I see it is that a class specifies a set of indistinguishable objects. Without object identity, the class cannot describe the structures of communicating objects that the users interact with.

The hard part of understanding DCI is to lift one's eyes from the class abstraction and open one's mind to an additional abstraction that applies to such object structures.

This discussion reminds me of Dijkstra's "GOTO considered harmful" 40 years ago. People, including me, got really angry. GOTO was the essence of programming and his letter to the editor of CommACM was heresy. The man was crazy! It took me several months of hard work to get rid of GOTO from my mental model of what a program was. But the result was that my programs were greatly simplified and other people could actually read them!

We are not asking you to get rid of anything from your mental model. We merely suggest that you add an object abstraction that augments the class and that retains object identity. We call it a Role.

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) { ... }
};

> Hi Achilleas Margaritis,
>
> @Thank you. By your insult I can understand that DCI is
> @another set of those things that do not work in
> practice.
>
> Insults can be entertaining, but they are rarely
> productive. I fail to see the how insults can affect the
> practicability of anything, one way or another.
>
> @Here is a challenge: explain DCI in one short paragraph.
> @Unless you can do that, DCI has no chance in the real
> @world.
>
> You are probably right due the short attention span of
> many experts. (Another unproductive insult. I find it
> easier to insult than to think and say something with some
> substance to it).
>
> Seriously: The prolific 19th century Danish philosopher
> and theologian Søren Kierkegaard once said something like
> this: "if you want to teach somebody something, you go to
> where they are and walk with them from there." (Quoted
> from memory). I have always taken this as challenge to
> myself as a speaker and a writer. In this case Jim and I
> only knew that our readers would come from many different
> specialities, have many different backgrounds and
> priorities, and come from many different cultures.
>
> Communication between people requires a common vocabulary.
> It is easy to describe DCI in one short paragraph assuming
> that our readers shared our vocabulary. For example: "DCI
> is about separating the code for system state from the
> code for system behavior". Very tabloid and doesn't say
> much. I expect the sentence can lead to many more
> questions than it answers.

I did not ask for a short explanation, I asked for the simplest explanation there is.

>
> We clearly do not have a shared vocabulary. If we had, the
> discussion would have been very different. Hence many more
> words than a single paragraph are needed. Success is only
> possible if both writer and reader are prepared to expend
> the time and energy required to establish such a common
> vocabulary.

I disagree. If one truly understands something, he/she can describe it in a simple way.

>
> "Here is a final challenge: explain Java in one short
> paragraph to a programmer who has never heard of Java
> before. Unless you can do that, Java has no chance in the
> real world." Hm. The shortest explanation I have heard is
> "metadon for C++ programmers".

You confuse 'simplest' with 'shortest'.

@This discussion reminds me of Dijkstra's "GOTO considered harmful" 40 years ago. People, including me, got really angry. GOTO was the essence of programming and his letter to the editor of CommACM was heresy. The man was crazy! It took me several months of hard work to get rid of GOTO from my mental model of what a program was. But the result was that my programs were greatly simplified and other people could actually read them!


NO.

Just no.

This discussion is not equivocal to "GOTO considered harmful". This discussion is equivocal to people asking you tough questions and you not being able to explain the answers. Instead, you are making excuses. Somebody has to put their foot down and simply tell you, "No."

@The hard part of understanding DCI is to lift one's eyes from the class abstraction and open one's mind to an additional abstraction that applies to such object structures.

So really what you are saying is "inclusion polymorphism considered harmful"? Sure, I can buy that, especially for "Object-Oriented Finance" applications like credit-default swap risk portfolio creation. Honestly, there is no need for the term "DCI Architecture".

However, if you were to ADMIT that this idea is a bit overpackaging of a basic idea that's been around forever, Jim and you would have to go to your book publisher and say the book has to be scraped or rewritten?

@No, we are NOT talking about what you call "compiler ojects", we are talking about runtime objects.

Your examples should be based on a pluggable, event-driven "architecture", then. That's the sort of architecture most architects I know use. Your BabyIDE looks like compile-the-world procedural programming to me.

@Achilleas
@You confuse 'simplest' with 'shortest'.

It's cool how they're wasting their breath responding to "insults" but "valid points" are not even so much as acknowledged.

They don't just confuse "simplest" with "shortest". They confuse "logic" with "politics". Somehow, they're under the impression they can break people into believing there is a radical new idea here.

Hey, I have a group of programmers I need to present an idea to about how they write their code. I'm going to use almost no code to do it and meanwhile keep berating them for not understanding the user's mental model.

> @Achilleas
> @You confuse 'simplest' with 'shortest'.
>
> It's cool how they're wasting their breath responding to
> "insults" but "valid points" are not even so much as
> acknowledged.
>
> They don't just confuse "simplest" with "shortest". They
> confuse "logic" with "politics". Somehow, they're under
> the impression they can break people into believing there
> is a radical new idea here.
>
> Hey, I have a group of programmers I need to
> present an idea to about how they write their code. I'm
> going to use almost no code to do it and meanwhile keep
> berating them for not understanding the user's mental
> model.


I've got one suggestion for you: talk less and listen more!

There has been some comments of the type: "Couldn't this code have been written differently/better". The answer is almost always yes; the Bank example is designed to exemplify important DCI concepts in the simplest imaginable program, not to teach programming style.

Some writers have asked for more complete and detailed examples. I have written an IDE for DCI-based programming in Squeak (a dialect of Smalltalk) and used it to code more examples. The first, relatively complete documentation of this work was published as a program and report 6 months ago. Much has happened since then, and I am close to releasig a new edition. The updated document includes three examples with commented code.

Rather than wait for the report to get to a state where I can show it to other people, I will be posting preprints of some of the chapters.

The first chapter preprint documents a working Bank transfer program. You find it at
http://heim.ifi.uio.no/~trygver/2009/bb5bank.pdf
I have also posted a description of the programming environment BabyIDE1:
http://heim.ifi.uio.no/~trygver/2009/babyide1.pdf
My BabyIDE/DCI home page has been updated:
http://heim.ifi.uio.no/~trygver/themes/babyide/babyide-index.html

I hope these posts answer some of the outstanding questions.

> > > You are way more infatuated with the abstract,
> academic
> > > angle of this topic than concrete examples of how to
> > build
> > > working systems. To prove my point, your references
> > are
> > > all academic stuff, such as Alan Kay's and Doug
> > > Englebart's visions of computing. There is nothing
> > wrong
> > > with linking to these things, but I am dumbfounded as
> > to
> > > why you aren't directly linking to the following:
> > >
> > > @DCI implementations also exist in C#/.Net (Christian
> > > Horsdal Gammelgaard), Ruby (Steen Lenmann), Python
> > (David
> > > Byers and Serge Beaumont), and Groovy (Lars Vonk).
> The
> > > Qi4J environment (Richard Öberg and Steen Lehmann) is
> > > pushing forward the ability to express traits in a
> Java
> > > environment.
> > >
> > > Why aren't you linking me directly to implementations
> so
> > I
> > > can play around with examples? One of Kay's big
> tenets
> > is
> > > learning should be constructive. Instead of letting
> me
> > > play, you're linking me to more theory that I have to
> > > digest before I can go play.
> > >
> > > No, no, no. Just no. Let me play with the code.
> > >
> > I'm not sure there's anyplace where that code has been
> > made public. I'll ask. It is not secret or anything,
> but
> > may not have been released publically. I'll post here if
> I
> > find a link.
> >
> > Anyway, this is an idea article. We'll be publishing
> more
> > articles exploring this area that will be more hands
> on.
> > We'll do something on Qi4J, but I would point out that
> > Qi4J isn't DCI. What they have in common is that DCI has
> a
> > concept of roles that is implemented with this concept
> > traits, and Qi4J provides a way to do that trait-like
> > concept in Java.
>
> As for the C# implementation mentioned I have only made a
> small proof-of-concept example, but I am working on a
> larger example, which will give a better impression of how
> nicely (or not) my implementation would work in a real
> application.
> The C# approach is to use C# interfaces for methodless
> roles, use C# interfaces and extension methods for
> methodful roles, and just use POCOs for context and domain
> object. To be concrete the following is a really short
> example:
>

> namespace AccountSample
[i]....excessive code, with casting![/i]
> 

I agree with an earlier poster, about DCI, IoC, AOP, and event based programming, all are seriously flawed:
* they obfuscate code
* they make it even harder to design, understand, test, and especially debug side-effects!
* they can lead to ironically unexpected, and nasty, binding side-effects, including hard to trace data security and thread-safety issues.
* indirect binding can seriouly slow down execution, because too much indirection can sabotage VM runtime optimisations.
* they are another place for the code to break, due to subtle bugs.
* any API which injects code, relies on a less secure code definition, or uses reflection to access object internals, maybe a security risk, or introduce hard to debug runtime bugs.

I looked at Qi4j, and found numerous stupid mistakes on the web site, including in the code examples, this didn't bode well for design and code quality, but I was still shocked at just how full of over-abstracted IoC, and verbose framework boilerplate code, the examples were! The examples even included reflection code, when a Facade class would have been simpler, and been ripe for VM runtime optimisations.

IMHO, a transactional money transfer would be better managed by separate immutable reversable command, multi-object lock, and transaction objects; these could be inherently thread-safe, easy to track, easy to test, trivial to audit, and be made to enforce business rules, without any need for arcane frameworks, IoC, AOP, dodgy injection wild-cards, or other unsafe dynamic programming recklessness.

Have a read the Specs? Really? That’s so unagile section of
http://www.joelonsoftware.com/items/2009/03/09.html
I suspect that the main reason for this back-breaking dynamic language nonsense, is that some Agile programmers have to do over-kill code abstraction, because of inadequate or out-of-date specifications; I've been there, it was not fun, it made quoting a gamble, due to creeping featurism, so caused significant delays for software delivery.

The developing financial recession/depression process has forced Development, at my employer, to realise that this specification inadequacy was untenable, so we now insist on bounded, signed-off specifications, for bespoke customer work; this allows realistic quoting, and rebuffs cheeky customer bugs, for the new, and often expensive, functionality.

>
> I've got one suggestion for you: talk less and listen more!

My suggestion is: Always demand the best code.

What should I be listening to? Can you point me to something I clearly seem to be missing?

> Have a read the Specs? Really? That’s so unagile
> section of
> http://www.joelonsoftware.com/items/2009/03/09.html
> I suspect that the main reason for this back-breaking
> dynamic language nonsense, is that some Agile programmers
> have to do over-kill code abstraction, because of
> inadequate or out-of-date specifications; I've been
> there, it was not fun, it made quoting a gamble, due to
> creeping featurism, so caused significant delays for
> software delivery.
>
> The developing financial recession/depression process has
> forced Development, at my employer, to realise that this
> specification inadequacy was untenable, so we now insist
> on bounded, signed-off specifications, for bespoke
> customer work; this allows realistic quoting, and rebuffs
> cheeky customer bugs, for the new, and often expensive,
> functionality.

Joel is great at the Harvard Business Review-style teethbrushing lectures. It works.

Quoting from the section *What does a program manager do?*: "A good rule of thumb is that it takes about one program manager for every four programmers."

We have six program managers and four full-time developers. For SaaS, it is a phenomenal model.

Your other comments were dead-on. The trouble is vendors push all these techniques to big companies trying to do real-time or same-day-services. Sad fact is the mainstream has no alternatives.

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

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

Derived from which kind of account?

If I'm transferring money from my checking account, you'd want it derived from Checking_Account, but if I'm transferring from a savings account it should be a Savings_Account. The idea is to be able to 'attach' it to whatever kind of account happens to be appropriate, so you'll want something like

class Source_Account {
   private Account*;
   ...
}

or maybe

template<class T> // T must be derived from Account
class Source_Account : private T {...}

if your Account class has the right copy semantics.

> Derived from which kind of account?
>
> If I'm transferring money from my checking account, you'd
> want it derived from Checking_Account, but if I'm
> transferring from a savings account it should be a
> Savings_Account. The idea is to be able to 'attach' it to
> whatever kind of account happens to be appropriate, so
> you'll want something like
>

> class Source_Account {
>    private Account*;
>    ...
> }
> 

Why would you design a Source_Account, Checking_Account or Savings_Account into your design and code in the first place?

Source_Account is just a role this account is playing at the time of transfer. Any account can be a source or a target, and will be at one point or another.

Your account really has only one set of semantics, though the details may vary. Whether it's a Checking, Savings (or mortgage account, 30-day notice account, nostro or vostro account, etc.) are different products sold on the basis of a common set of semantics of an Account, difference being interest charged or applied, notice period, overdraft, limits, customer segment, available transfer/payment types, etc. Your design really ought to allow the details to vary, while keeping the semantics the same - without requiring subtyping for different products.

> > Derived from which kind of account?

From the core Account class, possibly just an interface, which has an identification, holds an amount of money and its balance can be changed either positively or negatively.

> Source_Account is just a role this account is playing at
> the time of transfer. Any account can be a source or a
> target, and will be at one point or another.

Right. And Savings_Account and the likes are 'real' Account-derived classes with their particular semantics, they are the 'actors' playing roles.

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).

Luckily casting from Savings_Account to Source_Account is a compile-time technique and does not lose the runtime type information about who the Source_Account now really is; possible Account's virtual functions are correctly resolved as Savings_Account's one even when casted to Source_Account.

>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).