> On the contrary. Programming paradigms are exchangeable by
> definition. There is no right or wrong as you can choose
> any paradigm you like to get working software. It is an
> inherently irrational choice.

Yep. It's almost like the term "paradigm" was originally used: to mark different consistent but incommensurable views of the world. It was used to criticize the idea of linear progress and not few philosophers of science attempted to demonstrate that paradigms are a myth and everything worthwhile can be subsumed in a rational reconstructions of history. All those voices have become silent and I guess that's mostly because no one seeks for alternative worlds and world views anymore. In this particular situation the term "paradigm" has simply be subsumed by progress: there must be a best paradigm and usually the latest one is the best ;)

I will defer to Thomas Kuhn on the nature of scientific revolutions, and instead stick to what I know best.

In my experience, application design has changed over the years, and it can basically be dumbed down into the following trends at the toolkit level:

1) Making the model more view-friendly
2) Making the view more model-friendly

The biggest advancement has been data binding. A big question, however, is how to connect the two View and Model while simultaneously allowing for rich interaction.

The easiest solutions are to cheat: Put an IView factory method on the Model object(s) and have it display the view. However, this not only poorly captures rich interaction, it also effectively assigns creation of View objects to developers rather than designers. Also, unless the factory method is determining its object builder instructions from an external source, then it is inherently a compile-the-world application. I'm not convinced this approach -- what I call "the Microsoft Office model of application development" -- is right for everyone. Office might be the bestselling software in the world, but its unique.

Most software has a totally different set of UI/UX assumptions with regard to deployment. The underlying code may use the same patterns -- i.e., (Guarded) Command patterns for actions -- but the big differences are in deployment and decisions on what gets dynamically injected at runtime.

In a big way, that is what I keep harping on.

In Trygve's new example. he says the activity network is hard coded and brushes that off. However, to refactor his code to use mobile activity networks, he'd also have to re-jigger his controller object. "Paradigm" or not, it's compile-the-world metaphors and not driving hard at addressing the challenge of loose coupling plus readability.

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.

> 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

Bill, I think article authors were pretty clear on what they think should and what shouldn't go inside domain objects: methods which involve doing something for this single object obviously should be part of the object, methods which involve a complex interaction of multiple objects or involve services orthogonal to domain objects (i.e. transactions, serialization, or CRUD) are better to be outside of domain objects; normally, domain objects shouldn't even know about those methods to avoid coupling. So, domain objects are not anemic / dumb; they just don't try to contain parts not belonging to them.
A "container" / business logic layer / context - whatever we call this thing - obtains concrete implementation of those external methods using some kind of IOC/DI and executes them. If this pattern somehow contradicts "pure" OOP, I strongly oppose enforcing pure OOP here.
A very interesting variant of this approach called Making Roles Explicit was presented by Udi Dahan. Note, that Udi uses the same term "role" (although he's definitely a developer, not a person from academia :). He shows, among other things, that sometimes business logic layer even maps "roles" = external methods back to domain objects, in case domain objects include suitable functionality. This still keeps roles decoupled from BO.

I like how authors emphasize that roles represent behavior, action, rather than object structure.
What I don't understand from the above article is why would we want to use traits/mix-ins/extension methods or any other tool to attach those "roles" external to domain objects back to them? To me, these things are external and should belong to business logic layer.

A new version of BabyIDE/DCI program and documentation is now available from
http://heim.ifi.uio.no/~trygver/themes/babyide/babyide-index.html

The Documentation section gives access to the short article that started this blog and also the main DCI document called "The Common Sense of Object Oriented Programming". The latter document discusses details and rationale for DCI as well as commented code for three examples.

The Downloads section includes the latest Smalltalk/Squeak program (image) with examples. Follow the simple instructions to download the program; it is set up so that it is meaningful to programmers without prior experience with Smalltalk/Squeak. It is easiest to run the program under Windows, a bit harder for other operating systems.

There are also files for Squeak programmers who want to install BabyIDE and the examples in their favorite Squeak image.

John Zabrozki wrote:

> My objects render themselves

and

> Instead, I prefer
> to create truly object-oriented user interfaces.

John,

I'm very interested in your approach. Would you care to elaborate on this? E.g. I would like to know if your domain classes are tied to a given presentation model, or if you can reuse your domain model with both a Swing and HTML GUI?

Is your methodology well-defined and published, or is it based on years of experience? If the former, could you provide links/titles/etc?

It is based on years of experience and reading.

It is not based on any of Fowler's patterns. Instead, it is based on hypermedia concepts as well as other theories, such as hierarchical state machines, behavior trees (used in game programming), agent-oriented programming, feature-oriented programming, adaptive object-oriented programming, aspect-oriented programming, theories from information science such as Codd's relational model and Darwen/Date's relational model, master data management, etc. The biggest value in all these theories is that they establish proven reasons for why I write a particular chunk of code. Every line of code should have a purpose. I don't believe in calling something "architecture" if it's mainly a bunch of shunts and shims holding things in place.

For hypermedia, I was always interested in the work of PJ Brown (GUIDE), Ted Nelson (Xanadu), Douglas Englebart (the mouse, among other hypermedia contributions), Roy Fielding (REST) and EJ Whitehead (WebDAV). There was also in the '90s a bunch of methodologies for blending Object-orientation with Hypermedia, although I feel the papers were somewhat hard to read without trying to prototype the ideas in code while reading the paper. Also, Wikipedia taught me a fair amount about fancy caching of hypermedia. Wikipedia is the world's largest "composite/structured application".

For object-oriented user interfaces, I first heard about these my freshman year in college when Allen Holub published a series of JavaWorld articles on them, and I later bought the book <em>Naked Objects</em> by Richard Pawson and Robert Matthews. Neither of these resources are particularly good, though. Why? (1) Pawson sounds too much like a CTO giving a high-level overview, and he never really discusses core architectural concepts, despite bashing others (2) Holub focuses too much on simply eliminating "Getters", and doesn't go into much detail on application structuring. In fact, his book <em>Holub on Patterns</em> has some rather non-exemplary code. I suspect part of the problem is the weight of Swing; it's simply too hard to do anything radically OO in Swing. Just look at the Naked Objects Framework created by Pawson to see how limiting Swing is. Don't just look at the screenshots; look at the underlying code and extensibility points. Swing simply requires solving too many problems at the wrong level of abstraction to ever build a OOHUI (Object-Oriented Hypermedia User Interface) with it. Thankfully, Sun is starting to zero out Swing's budget.

For state machines, there is a long list of books on this subject. They all take different approaches. The real value here is in a model for REST's "Hypermedia as the engine of application state" principle. Most people don't get this principle whatsoever, and even joke about it by referring to their incorrect usage of REST as "Lazy REST".

I don't publish.

> E.g. I would like to know if your domain classes are tied
> to a given presentation model,

Why would I do something silly like that. The moment you have to vary the user interface, such as by user role to restrict permissions, your presentation model becomes needlessly complicated.

For what it is worth, I don't like Fowler's explanations of GUI Architecture. He doesn't really do a good job explaining the consequences of going down a particular route. However, bear in mind he's not committing serious time to these articles, either. My basic observation though is that Martin simply breeds trust, and it sometimes leads to people using his patterns for the sake of using one of his patterns, because there is a feeling you'd look foolish if you didn't.

I personally reject three layered architectures. They make no sense whatsoever.

I also reject traditional n-tier SOA architectures, because they are not event-driven but simply services-driven. I suspect in 10 years time the industry will finally transition to better practices; things like Enterprise Message Bus technology is finally maturing in the proprietary sector, which means FLOSS will be soon to catch-up. The trail has been blazed.

> or if you can reuse your
> domain model with both a Swing and HTML GUI?

I strongly believe in Model-Driven Architecture. Currently, a domain model maps to two UI platforms. However, that's not challenging. What has proved technologically challenging is creating an infrastructure for consistent styling, but our customers don't seem to care. They just want fewer mouse clicks and clean UIs. There are things like Mesh for skinning Struts applications, but they are Web-only. Currently, we use a rather monolithic cascading stylesheet language subset, and have our own CSS-subset interpreter on the Desktop. However, the level of styling is sort of limited compared to the sexiness you could get out of not using OO MDA, and just writing an Ext.js application directly.

As always, MDA is not cheap up front. Just look at how much of a struggle it is for Jim van Dam on the Eclipse RCP project to move to model-driven architecture. Not only is it hard for him, but it will likely be hard for others as well. He is a UML weenie, so in order to use his MDA approach you are locked into UML for your models. I'm not bashing UML, only pointing out that Jim's work is for "Fortune 100" Eclipse users.

Despite not being cheap, effectively modeling your architecture will simplify every decision you make after the fact.

John,
What is it about those products that appeals to you from an architecture perspective? What is the foundation?

What products are you referring to?

I didn't really list products so much as theories.

The foundation is quite large, which is why I don't formally define it.

Look at it this way: Ted Codd defined 333 guidelines for his relational model.

Now suppose you used a fair chunk of relational theory, but then also said to yourself, "gee, that Turing Award winner Charles Bachman guy who was Ted Codd's arch rival in the 70s, he had some good points about navigating large data banks." Fast forward to the late '90s, Roy Fielding is designing Apache and working on his Ph.D on how to design network-based architectures. He advocates disciplined use of hypermedia (REST) as a highly scalable model for information systems. So now you have something like 333 rules from relational theory, and now you tack on more from REST. And so on.

Most people don't realize how many theories they use when writing code or simply designing systems.

> such as hierarchical state machines, behavior trees (used

How do you do state machines? Framework supported or ad-hoc coded?

> > E.g. I would like to know if your domain classes are
> tied
> > to a given presentation model,
>
> Why would I do something silly like that. The moment you
> have to vary the user interface, such as by user role to
> restrict permissions, your presentation model becomes
> needlessly complicated.

How then do they render themselves while at the same time not exposing their innards to a potential "presentation layer"?

> > or if you can reuse your
> > domain model with both a Swing and HTML GUI?
>
> I strongly believe in Model-Driven Architecture.
> Currently, a domain model maps to two UI platforms.

Mapped, but not tied? Could you elaborate on the difference.

> Despite not being cheap, effectively modeling your
> architecture will simplify every decision you make after
> the fact.

Couldn't agree more, MDA or not.

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

I just wanted to point out that the MVC description - Figure 1 of the article and around it is not the original MVC which separates the View and the Controller portions which do not interact directly as it is shown on Figure 1. Please check with the original (30 year old) work of the professor Reenskaug. The picture an what you describe around it looks more like MVP and because of that all the critics around is not relevant to MVC.

@Jim says MVC is a flawed architecture. I agree.
If you think that MVC is flawed, it looks like you did not understand the basics. MVC is the way the mother nature built humans. It is the only way humans (and other living objects) actually interact with each other and the environment. In the psychology it is called beavioral stereotypes. Trying to replace one stereotype (fundamental MVC) with another one (less fundamental DCI) makes very little sense. The only implication will be the fact that those who now advertise MVC as the foundation of their frameworks will replace MVC with DCI in their adds (if DCI gets accepted; but it took over 15 years for MVC to get accepted; so it does not seem that DCi will get anywhere soon; probably, besides NetBeans where one of its architects already announced that MVC is obsolete).

@To John,
It looks like you missed the major point from the 'Naked Objects'. It is the idea to avoid spending lengthy hours on programming GUIs, but use the framework or one application that will display them for you in a standardized way. You may not like this standardized view, but you save your time and budget and avoid programming event listeners which you would do and probably continue to do (if you are involved with GUI implementation). Fortunately, Java and C# run-times allow the introspection for that.