> Does "use cases" mean Use Cases? Is the goal really to map
> Use Cases to code? Is that even desirable or achievable?
> Caveat: I didn't read the article on BabyIDE. Still, I
> think they are valid questions.

Use cases are useful for testing. They also give you a good idea for how well your class model describes the problem space (i.e., do i have lots of artificial boilerplate like in Spring vs. virtually no boilerplate in Seam).

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

It's simple once you drop most things you learned in your college OO education. I frequently give a one-hour talk on this at conferences. Most of the communities that formed to write code around their own programming languages were launched from that one-hour talk (the hour includes Q&A time).

This paper is more thorough and includes the historical exposition and a more complete rationale. Far too many current misconceptions were launched from pop articles on pop web sites and pop magazines. We're aiming at professionals who want to advance, or at least start, their thinking. Such thinking probably requires more of an investment in time than most pop site readers are willing to put in. I'm happy to reach the few willing to make that investment -- including going back and trying to develop the examples for themselves.

As mentioned above, there are many examples in the book manuscript --but, given your post, I'm not sure that book reading is for you -- unless it's a comic book.

>Trygve alleges DCI makes code simper to read. This makes
> code much harder to debug.

I find it easier to debug because:

1.The context switches across business functions are fewer and more closely follow the mental model (role-based) than the programmer model (domain-based);

2. Inclusion polymorphism is almost completely gone. When I call foo I get foo: not one of many foos up and down the subtyping hierarchy.

3. I can find a test point for something of business value: that is, I can really do BDD. That makes it easier to develop test cases to support debugging.

4. I do less run-time debugging because the code is more readable at compile time.

I do not understand your claim of why it's harder to debug. Do you have a running example? Try debugging the examples in the book manuscript.

> DCI challenges the assumption that each object has one and
> only one class. The observation is that objects need
> different behavior in different contexts. So why not let
> an object have a different class in each context? The way
> it shakes out is that you will have an anemic
> Account class in your design, and different
> traits that can be mixed into Account to
> supply just the extra (non-anemic) behavior needed for the
> use case at hand. And DCI also suggests is that use map
> these traits to conceptual roles in the user's thinking.
>
> Since you like code, let me show you how this maps to
> Scala, in which you can model it nicely. You can have a
> anemic class Account, and then mix in one ore
> more traits at instantiation time. So in the transfer use
> case, you might write:
>
>

> val source = new Account with TransferMoneySource
> 

Here's a stupid question and I don't mean to be rude but why not just use the term trait[/t] instead of DCI Architecture? Does DCI differ from (or add anything new to) a trait in Scala or Squeak?

> > DCI challenges the assumption that each object has one
> and
> > only one class. The observation is that objects need
> > different behavior in different contexts. So why not
> let
> > an object have a different class in each context? The
> way
> > it shakes out is that you will have an anemic
> > Account class in your design, and
> different
> > traits that can be mixed into Account to
> > supply just the extra (non-anemic) behavior needed for
> the
> > use case at hand. And DCI also suggests is that use map
> > these traits to conceptual roles in the user's
> thinking.
> >
> > Since you like code, let me show you how this maps to
> > Scala, in which you can model it nicely. You can have a
> > anemic class Account, and then mix in one
> ore
> > more traits at instantiation time. So in the transfer
> use
> > case, you might write:
> >
> >

> > val source = new Account with TransferMoneySource
> > 

> Here's a stupid question and I don't mean to be rude but
> why not just use the term trait[/t] instead of DCI
> Architecture? Does DCI differ from (or add anything
> new to) a trait in Scala or Squeak?
>
I can think of two reasons. One is that traits are more general than DCI. So DCI could be thought of one way to use traits, but there are many others. But also DCI attempts to live at a level above language constructs, as a pattern. So traits is one way to implement DCI. There may be others.

> >Trygve alleges DCI makes code simper to read. This
> makes
> > code much harder to debug.
>
> I find it easier to debug because:
>
> 1.The context switches across business functions are fewer
> and more closely follow the mental model (role-based) than
> the programmer model (domain-based);

I am not sure this is proven. There is no direct comparison for me to understand your point clearly.

> 2. Inclusion polymorphism is almost completely gone. When
> I call foo I get foo: not one of many foos up and down the
> subtyping hierarchy.

I will agree that this is what most F# programmers hate about C# style languages.

> 3. I can find a test point for something of business
> value: that is, I can really do BDD. That makes it easier
> to develop test cases to support debugging.

Suppose I'm a robot and don't have as good of an imagination as I put on -- I burn my creativity at work. Explain this to me directly.

> 4. I do less run-time debugging because the code is more
> readable at compile time.
>
> I do not understand your claim of why it's harder to
> debug. Do you have a running example? Try debugging the
> examples in the book manuscript.

Trygve's BabyIDE and Christian's test harness aren't pluggable, event-driven models. Trygve hardcodes sequences of collaborations in his mediator pattern usage. Christian does as well.

Applications exist on multiple continuums, one of which is:

<-[vague]-----[core data structures]-----[detailed]->

An architectural pattern should say stuff about these things. And so should good API design. Unfortunately, most APIs assume you know all your targets at code-write-time. My challenge to Trygve is to make such code more readable. It is easy to do a news report and explain what happened. It is much tougher to write poetry.

It's my major complaint about MVC, too. People think *anything* in MVC can be a model, including a View. Clearer guidelines produce more robust designs than compiler features. Even though I hate DDD, this is the one reason it works so well!!!

Hi Robert,

> Just how important are traits (or equivalent programming
> language constructs) to DCI? In the Scala example, we
> mixin the trait to the Account class. But it seems
> apparent that, at least for the article's example, we
> could implement the same in Java (without Qi4j) by
> injecting an Account into an instance of a
> TransferMoneySourceAccount.
>
> Or, to put it another way -- in certain dynamic languages
> such as Ruby (hand waving alert:I am no expert on Ruby), I
> believe we could do a mixin without an explicit coupling
> between the methodful role/trait and the Account object.
> Is this a real advantage? Does the Scala implementation
> n lose something by coupling the trait to the Account?
>
I think a mixin in Ruby is an analogous concept to traits in Scala. The main difference comes from the fact that Ruby's mixins are dynamic and Scala's mixins are static. (In Scala, when you actually use a trait, mix it into a class, you can also call it a mixin.)

As far as the advantage of traits over dependency injection in Java, I think you can get the same functionality, but you'll end up with more code in Java. You can write by hand in Java what the Scala compiler does for you when you mix traits into classes in Scala. It's just a lot more code in Java. But it is also a level of abstraction effect. I think all that code required in Java would make it harder to think at the level you think of in Scala when working with traits.

@There are five people in the world who remember everything that has ever happened to them.

I can't see a way for you to prove that exact number. Even if it's relevant do the article :)

@It's my major complaint about MVC, too. People think *anything* in MVC can be a model, including a View. Clearer guidelines produce more robust designs than compiler features.

I agree. Strongly. Both MVC and DCI need specific environments to run. The source code written in the spirit of MVC or DCI must be executed in the "context" of application executable, web server, operating system etc. The specific code could be treated as example of MVC or DCI not because of how it looks like but what it does.

In FSM or Petri Nets there is a "magic hand" capable of changing states or passing tokens between channels and instances. In DCI, as for now, I can't see what is passed and where and how it is done. I assume, the "context" is passive element of the graph (node), the edges should be "roles" or "interactions", but what is the rule, responsible for decision on what element of the graph should I look at that particular moment of time?

> > 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.
>
> It's simple once you drop most things you learned in your
> college OO education. I frequently give a one-hour talk on
> this at conferences. Most of the communities that formed
> to write code around their own programming languages were
> launched from that one-hour talk (the hour includes Q&A
> time).
>
> This paper is more thorough and includes the historical
> exposition and a more complete rationale. Far too many
> current misconceptions were launched from pop articles on
> pop web sites and pop magazines. We're aiming at
> professionals who want to advance, or at least start,
> their thinking. Such thinking probably requires more of an
> investment in time than most pop site readers are willing
> to put in. I'm happy to reach the few willing to make that
> investment -- including going back and trying to develop
> the examples for themselves.
>
> As mentioned above, there are many examples in the book
> manuscript --but, given your post, I'm not sure that book
> reading is for you -- unless it's a comic book.

Thank you. By your insult I can understand that DCI is another set of those things that do not work in practice.

Here is a challenge: explain DCI in one short paragraph. Unless you can do that, DCI has no chance in the real world.

By the way, isn't the Internet a wonderful place where any stranger can insult you without any consequences? :-)

@As far as the advantage of traits over dependency injection in Java, I think you can get the same functionality, but you'll end up with more code in Java.

DI frameworks are simply boilerplate removal mechanisms.

A more fair boilerplate comparison for DCI would be a mobile code framework such as Nat Pryce's Babble.

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.

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.

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

@We clearly do not have a shared vocabulary.

We do, and it is called CODE!

Describe the problem with existing approaches by showing how unreadable their code is.

You don't unify a vast audience with a strawman.

I concur. I don't see why the responsiblity for orchestrating the transfer should belong to either the "source account" nor the "destination". This is similar to the age-old OO argument of whether it should be "cake.bake(oven)" or "oven.bake(cake)". Moving it from the source to the destination doesn't made it any better.

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.

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

It certainly seems that way.

Jim wrote the forward to Selic's book Real-time Object-Oriented Modeling, which centered around software construction using state machines. Now state machines are "nerd-centric" and Jim can't be bothered to show me directly by comparison how his new approach is better. Despite the fact he clearly should know a ton about FSMs, since he wrote the forward to a book on my shelf about them.

But, oh wait, I can buy/read his new book... which probably won't answer my question.

The fact of the matter is I've yet to see a "DCI Architecture" fully working program that is event-driven and pluggable, so it is fundamentally not SOA or OO. So far it is compile-the-world procedural programming. Any "events" in DCI are hardcoded sequences of collaborations Steve Mellor calls The Mongo Controller Object Anti-pattern.