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

I'm happy to reciprocate.

> 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


To be a deconstructionist, you just presented a solution to my problem without either telling me what problem you see in my writing, what contribution to plan to make, or any data supporting your claim.

There are many styles of writing for many audiences. I teach English composition in Universities and, for what it's worth, have written some critically acclaimed books and have often been commended by no less than the ACCU folks for writing style alone. Perhaps you expected something different than what we wrote. That's O.K. No one forces you to buy okra when you go to the store. Don't accuse the vendor for selling okra.

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

This article introduces the architecture, with examples. It is the first in an article series. I wanted to leave room for Richard and others to follow up with their concrete examples insubsequent articles.


> By presenting the strawman that "programmers just don't
> get MVC, but it works",


Er, where does the article say that?

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


Traits are just a shill. Don't confuse the example with the fundamentals of the problem and solution. Yes: we've overlooked the fundamental concepts. Now we have a solution. Traits are one way of rendering the solution but they may not be the only one.

So I think your concern is at least grounded in that misunderstanding. I think your concern is actually more fundamentally displaced, but suffice to point out this ignorance at this point.


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

And what does that have to do with the price of peanuts?

> But you fail to tell me how to do this [create a designer-developer facade] (I know how, but
> just follow me).

Er, that's not the point of the article nor what we are doing.

From this point on, I think your inferences draw on the above misunderstandings and so don't need to be visited one-on-one.

In a nutshell, the problem is that 1. OO is supposed to capture mental models; 2. There are mental models that we missed; 3. Roles and the algorithms that run through them are the missing part, and 4. DCI makes it possible to express those in the code. There is nothing about facades.
Traits are one technique, not the essence.

It took me ten years of Trygve beating on me night and day to see this clearly. Maybe when your 14 gets up to my 40, you'll get it, fine young man :-)

Please think clearly.

Trygve, Jim, it's great to see a full exposition of this. The one thing which strikes me, though, is that you make your argument in terms of "going back to the user's head" and then you add roles to a use case description which does not mention them.


If we're going back to the user's head ("Data: representing the user's mental model of things in their world") wouldn't we be better off with the use case itself rather than the role annotated description. It seems that in your process, you take the user's view and then substitute for it an anthropomorphic view which is convenient for us as designers -- even to the point of privileging the source account role (you give it the self for the behavior).


I don't there that there is anything wrong, per se, but given the original goal, it seems to me that having behaviors which were named specifically after the use case would make sense. They would be like procedures or multi-methods, not strongly associated with either the source or destination roles. People adopt that model now, by formulating transaction objects which map to the user's conception of an interaction.

@By the way, I have no idea what a "problem domain analysis class is." Can you be more precise?

Thanks, a common vocabulary is important.

An analysis class captures some indivisible aspect of the problem domain. Great examples of analysis classes are in Fowler's book Analysis Patterns.

@Yes. A Use Case is a contract between an end user and a system under construction. Too many programmers take this beyond analysis into design. The Use Case ends up being pseudo-code that over-constrains the ordering of processing as well as other design choices. A Use Case should focus on "what," not "how."

The benefit of a use case is it is something both the user and engineers can understand and agree upon.

The benefit of a framework is it is something you can use regardless of small details captured in use cases. In that sense, at some point you need to talk about making sausage-things the user doesn't care about. If you get your gross application structure wrong, then there is no way you are going to stabilize design. A designer-developer facade is also focused on "what", but leaves out implementation details such as perhaps using "nerd-centric" state machines.

The classic example of this is the Browser. The idea that you have a client responsible for negotiating formats with a server and also responsible for knowing how to render those formats is anti-OO. Actually, this is a point Alan Kay makes very clear in his 1997 OOPSLA speech The Computer Revolution Hasn't Happened Yet.

@Are you seriously going to put something other than the system in your problem domain analysis?

Well, that's what I do now. I don't say "The system displays valid accounts", because a System object is way too vague to assign responsibilities too? Moreover, intuitively, it has a "God class" feeling to it.

I am suggesting that you are backing yourself into false premises with statements like these in your article:

@Unfortunately, object orientation hasn't fared so well to capture how we reason about doing. There is no obvious "place" for interactions to live, either on the GUI or in the code. There are exceptions to this rule, particularly for simple actions that involve only a single object.

In practice, you are very, very, very correct in describing how most people write their OO code. But they're also sharing too many implementation details, which is obviously counter to OO. If you want to tell me that traits are a way to provide syntax so developers STOP their bad practices and finally practice the 00 oaths, then that is different. You and I both know compiler syntax features are important, because we can't expect the average developer to be a compiler writer and invent great DSLs -- it's been tried in the past and doesn't work.

I fully understood your point, here, and it is a really hard one to explain -- which is why I'm pushing you so hard. However, there is absolutely a place for interactions to live.

I'll give you examples of things I see as OO anti-patterns that may better illustrate your point. Presentation-Abstraction-Control is an architectural pattern like DCI and intended to address issues such as multi-object interaction. However, the pattern is ultimately ad-hoc case statements (that is what the Control object does at every layer). Yet, it is pitched as "MVC for multi-object interaction".

Another thing you can consider pedagogically is borrowing examples from your competitors. You shoot down state machines as being "nerd-centric", so hopefully you are well-read on the classical examples in FSM literature. However, I'll point them out to you: Ian Horrocks' book Constructing the User Interface presents several examples, beginning with non-OO VB code representing the interactions for a calculator. He then discusses how a HSM can clarify requirements and eliminate bugs. This example was copied by Miro Samek in his two Statecharts books, and he calls it The Ultimate Hook pattern. http://www.state-machine.com/devzone/Pattern_UltimateHook.pdf

Something similar to role-based modeling is Karl Lieberherr's Demeter Tools. All you have to do is write propagation directives targeted at what a Scala developer might call a "case class". In addition, because Karl uses a parts-centered object model that is easier to type-check and express parts-invariants, it is possible to specify business rules (albeit not so clearly, but that is an artifact of not taking the idea to its logical conclusion).

@It took me ten years of Trygve beating on me night and day to see this clearly. Maybe when your 14 gets up to my 40, you'll get it, fine young man :-)

I hope the secret to writing great software isn't 40 years of experience. Surveys show the average career in high-tech is 7. You need to reconsider your end game. I may be dead in 26 years. :-)

@From this point on, I think your inferences draw on the above misunderstandings and so don't need to be visited one-on-one.

Maybe... but were my examples of existing technology like Struts ans Seam examples that you could actually relate to? Have you used these technologies? If not, then I'm giving you technical ideas to continue this debate. At which point, all you are going to hear/see is "I'm trying to get you to think clearly."

If you think my technical examples are something you can't relate to, then say so. I have a wide breadth of experience, but I have never worked beside you and despite reading all of your books don't have any knowledge of your real-world project experiences. I know you as "the C++ guy on my bookshelf."

@ People adopt that model now, by formulating transaction objects which map to the user's conception of an interaction.

Are you referring to Martin Fowler's Transaction Script pattern? I couldn't gather what "that" is that you're referring to. http://martinfowler.com/eaaCatalog/transactionScript.html

If so, Transaction Scripts in my experience are horrible for interactivity: it requires a round trip to the server to determine validation failed. You don't have a notion of validation or business rules. Transaction Scripts also poorly model multi-object interactions that take place prior to the user clicking Commit (or some facsimile).

@To be a deconstructionist, you just presented a solution to my problem without either telling me what problem you see in my writing, what contribution to plan to make, or any data supporting your claim.

OKay, I'll bite.

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.

Instead, Bill Venners is linking for you and providing us with the url to Qi4j.

When you were standing next to Robert Cecil Martin at the MIT agility conference, the differences between you were so striking. Most practitioners I know in the audience felt that they could relate much better to Uncle Bob, because he was expressing stuff they were comfortable with: write the tests and then the code. Simple, pragmatic stuff.

I love approaches like Bertrand Meyer's, where he has students work on a 150,000 SLOC Eiffel code base and gives them the freedom to break stuff and understand why thngs are the way they are.

With programmers, it can be very hard knowing your audience. When speaking or writing, I've done much worse than you have here. The primary enemy is the fact it is so darn tough to get a roomful of 15 programmers who share common backgrounds, both in theory and practice.

However, there is one thing you can pretty much rely on programmers knowing how to do: testing and debugging code.

Steve McConnell got it right in Code Complete: construction is the only phase of software you can provide reliable advice and common ground for.

On a separate matter, your diagrams are very poor. You have spaghetti lines tracing from your DCI half to your MVC half. You should explore the benefits of consistent positional notation in your diagrams. The benefits are well-argued by the CASE Method folks. Actually, these spaghetti lines give the impression that the name-space relationships in DCI are going to be inherently hard to visualize, and in most cases they are probably actually easy to visualize. In fact, one of the "features" of Data Flow Diagrams championed by DeMarco is that they give you "deep zoom": top-down design in a DFD is trivial because all you do is "step into" a process to specify its details at a lower layer in the problem domain. In fact, because control is not specified in a DFD, you can also "step over" without worrying about missing something. At any given point in time, you are looking at one instantiation of a navigation relationship.

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

If implementations aren't public, they're vaporware. Duke Nukem Forever could be using a DCI Architecture for all I know, but DNF is still vaporware. This is like when academics site a paper with the promise it will be published at a later date, and then never is.

Along the lines of ideation, consider asking Glenn Block, Hamilton Verissimo or Nicholas Blumhardt to talk about .NET's Managed Extensibility Framework. Rinat Abdullin could also be another interesting person to talk to.

I hope you don't find my feedback out-of-place, Bill. Part of the reason people publish idea articles is to get critiques. And I'm the epitome of blunt -- it sometimes overshadows my thoughtfulness and how attentive to the topic I am actually being.

You build a community based on working code. If it's taken 10 years just to get Jim and Trygve see eye to eye, there must have been some code written out there to publish?

Even if you can't provide working code for your idea, you can at least provide working code for existing approaches and show why they're so inadequate.

And if you make the case that your approach is similar to but less nerdy than FSMs, show it. I found this particular point hardest to grasp, as it is not clear to me yet how Jim sees me taking advantage of my spatial intelligence in the same way a statechart does. Moreover, new GUI toolkits like Silverlight formerly use FSMs in their API -- it's an old academic idea finally put into practice.

For what it's worth, I carefully incorporate architectural constraints for dynamically varying things by role, and I reason about parts of my system using FSMs. I see these two approaches as complementary, not divisive nerd-centric vs. user-centric.

It think what's missing in the article to understand DCI is the definition of role in this context:

We will now look at how the word role is generally used and see how this usage can help us build an intuition about our use of the word in object oriented programming. Most people will probably associate the word role with a part played by an actor in a theatrical performance. Oxford [9] gives its origin: "from obsolete French roule ‘roll’, referring originally to the roll of paper on which an actor’s part was written." (Note that this means the script, not the performance!) Oxford [10] has a fitting definition: "Actor’s
part; one’s function, what one is appointed or expected or has undertaken to do." This maps nicely on to our use of roles for naming the participants in a system of collaborating objects; the role is a reference to an object; it represents the object’s function, what it is
delegated or expected or is required to do.

Excerpt from: http://heim.ifi.uio.no/trygver/2007/roles07-rolesandclasses.pdf

For examples see Jim's book draft:

http://sites.google.com/a/gertrudandcope.com/info/Publications/LeanArchitecture.pdf

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.

> Ian Horrocks' book
> Constructing the User Interface presents several
> examples, beginning with non-OO VB code representing the
> interactions for a calculator. He then discusses how a
> HSM can clarify requirements and eliminate bugs.

I've just had a quick look on amazon.co.uk for that book; prices range from £112 to £248. Now, if only I could get someone to buy it for me...

I don't recommend copying Horrocks' designs. He hardcodes in entry/exit guards and actions. This is a brittle design.

The nice thing about the Silverlight approach is that you can store the object model in a "stylesheet". Unfortunately, because it doesn't use a functional reactive programming model, it can't merely recompute the differences. There is also two other flaws with the Silverlight model, but on the whole I like it much better than other models.

You can always e-mail the author to ask the publisher if he can provide a copy of the book online for free now that it is out-of-print. Harel did this for his Statemate book. http://www.wisdom.weizmann.ac.il/~dharel/reactive_systems.html

> If implementations aren't public, they're vaporware. Duke
> Nukem Forever could be using a DCI Architecture for all I
> know, but DNF is still vaporware. This is like when
> academics site a paper with the promise it will be
> published at a later date, and then never is.
>
The reason I wanted to publish this article is to give readers some new ideas to think about. So I think you're a bit hung up on the code aspect. This article is about the ideas. I think implementing DCI is awkward in most of today's popular programming languages. That doesn't mean its a bad idea. Implementing an object-oriented program in C or Fortran is awkward. Scala's traits may capture it nicely, and I suspect Ruby's mixins would too. The paragraph that mentions languages and names I suspect is there to give some credit to the folks who did that, but what I think they did is simply implement the account example in the languages mentioned. But this isn't about how to do things given today's programming languages, but rising above that, asking how can you make code easier to understand.

This article is academic in the sense of people aren't using DCI in mainstream programming circles. I don't see that as something wrong. It is a new idea, an attempt to improve things. Maybe it will pan out maybe it won't. It is also still evolving. But the whole thing is aimed at solving a very real-world problem, which is that it is hard to understand programs.

One of the things I took away is that I don't believe I've thought about designing objects to map to the user's mental model. I work hard on naming things and coming up with clear concepts, but from the perspective of programmers working on the code. Domain Driven Design recommends using the same vocabulary used by the domain experts in the code, but that also isn't the same thing as the user's mental model necessarily.

Another take-away for me was Trygve's concern that the logic in a traditional OO program is spread out all over the place. So to him OOP was a bit of a step backwards in ease of understanding code compared to procedural programming. DCI is an attempt to improve the understandability of OO programs.

Another thing I found interesting was the suggestion that the domain objects be very simple ("dumb, dumb" as Jim put it). This seems to promote what Martin Fowler and Eric Evans called an "anemic" domain model:

http://martinfowler.com/bliki/AnemicDomainModel.html

These guys complained that you should put more interesting behavior on those objects. Well, this article points out that sometimes you can end up wanting to put too much stuff in those objects, and that different subsets of all that behavior may be needed in different contexts. Well, their notion is that you model that extra stuff in traits, and that the traits would map to roles in the user's mental model. And then in a particular context, or use case, you add on the traits that you need for that context to the dumb domain objects. Now they aren't anemic anymore, and they only have the extra behavior that's needed for the current context.

Having worked with Scala for a while now, I've really seen the usefulness of traits, and this article gave me a new idea for how traits could be applied. I'm still not sure how this would make the code more readable, because it seems like things are now spread out among traits. Though I think the home of the algorithm we used to easily see in a procedural program may be the "context". Perhaps Jim or Trygve could clarify that for me.

One other place you might want to look if you want to see some DCI code is Trygve's BabyIDE project, which I believe is implemented in Squeak. I have not looked at it, so I don't know what it's status is:

http://folk.uio.no/trygver/themes/babyide/babyide-index.html

> > 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
{
	// Methodless roles
	public interface TransferMoneySink
	{
	}
 
 
	// Methodfull roles
	public interface TransferMoneySource
	{
	}
 
	public static class TransferMoneySourceTraits
	{
		public static void TransferFrom(this TransferMoneySource self, TransferMoneySink recipient, double amount)
		{
			Account self_ = self as Account;
			Account recipient_ = recipient as Account;
 
			// Selfcontained readable and testable algorithm
 
			if (self_ != null && recipient_ != null)
			{
				self_.Withdraw(amount);
				self_.Log("Withdrawing " + amount);
				recipient_.Deposit(amount);
				recipient_.Log("Depositing " + amount);
			}
		}
	}
 
 
	// Context object
	public class TransferMoneyContext
	{
		// Properties for accesing the concrete objects relevant in this context through their methodless roles
		public TransferMoneySource Source { get; private set; }
		public TransferMoneySink Sink { get; private set; }
		public double Amount { get; private set; }
 
		public TransferMoneyContext()
		{
			// logic for retrieving source and sink accounts
		}
 
		public TransferMoneyContext(TransferMoneySource source, TransferMoneySink sink, double amount)
		{
			Source = source;
			Sink = sink;
			Amount = amount;
		}
 
		public void Doit()
		{
			Source.TransferFrom(Sink, Amount);
			// Alternatively the context could be passed to the source and sink object.
		}
	}
 
 
	// Abstract domain object
	public abstract class Account
	{
		public abstract void Withdraw(double amount);
		public abstract void Deposit(double amount);
		public abstract void Log(string message);
	}
 
	// Concrete domain object
	public class SavingsAccount : Account, TransferMoneySource, TransferMoneySink
	{
		private double balance;
 
		public SavingsAccount()
		{
			balance = 10000;
		}
 
		public override void Withdraw(double amount)
		{
			balance -= amount;
		}
 
		public override void Deposit(double amount)
		{
			balance += amount;
		}
 
		public override void Log(string message)
		{
			Console.WriteLine(message);
		}
 
		public override string ToString()
		{
			return "Balance " + balance;
 
		}
	}
 
 
 
	// Test app
	public class Program
	{
		public static void Main(string[] args)
		{
			SavingsAccount src = new SavingsAccount();
			SavingsAccount snk = new SavingsAccount();
 
			Console.WriteLine("Before:");
			Console.WriteLine("Src:" + src);
			Console.WriteLine("Snk:" + snk);
 
			Console.WriteLine("Run transfer:");
			new TransferMoneyContext(src, snk, 1000).Doit();
 
			Console.WriteLine("After:");
			Console.WriteLine("Src:" + src);
			Console.WriteLine("Snk:" + snk);
 
			Console.ReadLine();
		}
	}
 
}

@Another thing I found interesting was the suggestion that the domain objects be very simple ("dumb, dumb" as Jim put it). This seems to promote what Martin Fowler and Eric Evans called an "anemic" domain model [...] These guys complained that you should put more interesting behavior on those objects.

Well, that's easy to reconcile. Evans/Fowler vs. Coplien/Reenskaug is not a battle of diametrically opposed forces. Instead, they're both wrong.

The big idea behind dynamic, multi-object interaction is that it is composed at run-time. You will have code fragmentation in order to do this. As you pointed out, their solution just pushes the fragmentation around and into traits. They're moving mounds of dirt, not setting up foundations for an architecture.

Rich domain models are wrong because the assumption is placing logic in one place (a domain class) is a good idea. Maybe, but you lose a degree of freedom and are creating an unstoppable geometric progression. Then there are awkward "N-Body Problems" where objects need to coordinate and no one object is in charge.

Anemic domain models are wrong because they flatten an architecture into orthogonal layers, requiring developers to pass tramp parameters to pass an object across multiple layers. This is fundamentally not OO, it is a data-driven CRUD/USER pipeline. This is the kind of app Spring and Struts and much of ASP.NET encourage writing. The POJO Facade pattern is a great example, and the book "J2EE Design Patterns" is a great example of OO anti-pattern after OO anti-pattern: breathtaking, really! Until J2EE5 and EJB3, Java land has been very far from OO theory&practice.

A major culprit here is buzzwords. So you'll forgive me if I snort when I see sections of an article with the header: "in spite of capturing structure, OO fails to capture behavior". The whole point of the GoF design patterns was to explain how to do dynamic substitution of behavior.

A more even handed approach is what Microsoft is trying to evangelize w/ Acropolis, Prism, MEF and Oslo, but very few seem to be adopting due to its immaturity. Redhat's JBoss also deserves some credit. Are you familiar with Redhat's JBoss and Microsoft's upcoming products?