If you mean whether you can assign any behavior to any ‘object instance’ in runtime, then the answer is; “No, we have been there and it is a nightmare to troubleshoot such systems. We appreciate type-safety and predictable structure, which variable instance types doesn’t allow.”

However, we recently added (not yet implemented) “Abilities”, where we have recognized that the behavior/interaction is purely defined by the client context, and we have concluded that the object instance must have a particular “Ability” for it to be able to fulfill the context role. So, the Ability is declared as a PartOf the object instance (composite in our terminology), which allows the ability to have non-public access to the guts of the object instance.

So, if I have a composite type called Person, I can “add” an ability, such as Employable, to such Person at assembly time, which a new subsystem can interact with, without affecting Person’s other contexts. And the Employee role will only interface with the Employable ability of the Person.

A final note, we have gotten a lot of flak for choosing to build on top of Java, and not create a new language instead. What people tend to forget is that it takes a few billion dollars of investment to get a language to the level of Java or dotNet, in terms of tools, acceptance, libraries, knowledge-base and developer training. Such practicalities are often forgotten in academic debates, and we have consciously taken a pragmatic approach of getting our ideas out there now and not in 10-15 years. However, we don’t rule out the possibility of Composite Oriented Programming (COP, nothing to do with Coplien ) languages in the future, either from us (the Qi4j team) or from others.

First, regarding refactoring: I don’t think I said that you should avoid it altogether. You should leave code cleaner (mere tydeligt) than you found it, but you should not expect refactoring to rescue you from weak architectural practice. Refactoring is about structural improvements that leave the functionality invariant, and it’s difficult to reason about functional invariance when making coordinated changes across architectural units. But it’s something I do, and that good coders should do, when making changes within architectural units.

More importantly, the core DCI concepts and the name itself come from Trygve Reenskaug, father of MVC. I’ve supported Trygve and provided useful input and feedback on DCI over the years — and particularly in recent months — but history should remember him as the patient explorer who brought this idea to life. Sometimes it gets a little difficult to separate who contributed what, but as someone who has worked closely with Trygve on this I want to be clear that the original ideas are his.

The main ideas behind DCI are to support a highly dynamic association between roles and objects that changes with every Use Case scenario; that roles take on the identity (in terms of the binding to self or this) of their associated object when they execute; and that the algorithms derived from end-user Use Cases directly be readable in the source code.

Various languages and frameworks address various of these problems. For example, Scala’s traits cleanly allow one to associate roles with objects and solves the injection problem. Python can very elegantly and directly express the semantics of class composition. C++ can also do the class-gluing in an elegant but static way; it is expressive and efficient, but leads to large configuration management costs in most environments.

Qi4J is an O.K. interim approach to achieve class composition in Java, but it’s not clear whether it in itself supports (or even allows) the DCI notion of dynamic role/instance association. Michael, can you clarify this?

However, none of these approaches lets me reason about the Use Case algorithm solely in terms of roles. No language solution in itself provides a solution to dynamically map roles to objects, though this easily can be encapsulated in Context objects in most languages. Qi4J’s contribution seems to be limited to a set of annotations that allow a Java programmer to express the kind of semantics one gets with traits in Scala (much as Michael says above), but doesn’t say anything about scenario expression or management.

So we still have work to do. Trygve’s Squeak implementation achieves the full vision.

JaOO was a great event for DCI in that it provided a melting pot for Lars Vonk’s Groovy implementation, Serge Beaumont’s Python implementation, Bill Venners’ Scala implementation, some noble attempts in Java by Agata Przybyszewska, the Qi4J input from Michael and Rickard, and lots of other input from lots of other bright people. It was gratifying that most people really get this — enough that there were lots of little groups sitting off in their corners at the conference slinging DCI-like code. This is much more than just a programming technique; it bodes broadly for design and for the highest-level patterns of software architecture. It was gratifying that the folks at JaOO got that (well, maybe one or two people didn’t…) Watch for an article series on artima.com where this new little community will give away its ideas for the greater good. We’re having fun and hope more people join us!

(For those who want to learn more about DCI in detail, get the paper from Trygve’s home page at http://folk.uio.no/trygver/2008/commonsense.pdf).

A Ruby implementation, anyone?

Just check it out, there is already a lot of documentation material and release 0.4 is out since two weeks ago.
qi4j.org

Michael

Agile is like teenage sex – everyone talks about it, very few are actually doing it, and those who do usually don’t do it very well.

I should just clarify he meant sex BETWEEN teenagers, not set WITH teenagers. Probably worth clarifying that!