Symbian Blog

Last week I was at Øredev 2009 giving a talk about what we, at the Symbian Foundation, have learned in the last 8 months. Øredev was a very interesting conference: lots of different topics were covered ranging from Agile, Architecture, …, Mobile 2, …, Test, to Web Development.

One topic which stuck out for me was a series of talks about a new programming model called Data Context Interaction, given by Trygve Reenskaug, who created the Model-View-Controller programming pattern, James O. Coplien and Rickard Öberg.

Crossing the Chasm between End User and Programmer

The fundamental premise of Trygve Reenskaug’s talk to introduce the topic was that in many cases OO as it’s implemented today falls short of its original intention of unifying the mental models of the end user and the programmer. The mental model of the user is expressed during run-time: in use-cases and interaction of the user with objects, and objects with objects. The mental model of the programmer is in classes, attributes and methods. The problem is a disconnect between both models that Trygve calls ‘the chasm’. Unfortunately, that disconnect is formalized in today’s OO languages, which Trygve calls Class Oriented Languages and James calls Your Grandfather’s OO.

The disconnect between code on source files and the run-time behavior of objects causes a number of problems. Let’s look at a few – but note this is by no means a comprehensive list:

• Class Juggernauts: When programming in your Grandfather’s OO, classes tend to accumulate code describing interactions between objects. Object A sends a message to object B and code specific to the interaction ends up in the classes of both objects. In real-life applications, with large number of interactions, classes grow bigger and bigger.
• Noodle Soup: Code that is part of a use-case tends to be distributed across many classes and many files. The consequence of this is that it is almost impossible to follow the logical flow of the use-case. Everybody who has debugged a Java or C++ app knows that the control flow jumps from class to class.
• Peer Review – Nearly Impossible: This makes peer review very difficult. Humans can only understand problems if presented in chunks of a certain size. Your Grandfather’s OO counteracts this as algorithms are dispersed across many different source files.
• Code Correctness can only be explored by tests. In OO often you fix one thing and break another. The only way to avoid this is to have comprehensive test suites.

Some people say that this is all a consequence of complexity: the talks made the case that this is the consequence of an insufficient theoretical foundation for object oriented programming.

So what is DCI? Think The Matrix !

The Data Context Interaction architecture creates the theoretical framework for mapping use-cases directly onto programming constructs. It does this by introducing a number of concepts that enable a programmer to map use-cases onto programming artefacts:

• Data Objects are dump objects that encapsulate data. They encapsulate what objects are: they do not contain any behavior. Let’s look at the use-case of transferring money from one account to another. What would a bank account object look like? In the DCI world the account object would only be able to increase, decrease, show the balance and the history log.
• Roles = Interaction: Roles capture behaviors that are about what objects do. They encapsulate algorithm and abilities to interact with other objects. Going pack to the banking example, we have two types of roles: the role of a source account and the role of a destination account. Now one could think that this example is trivial: however, in a real-life banking situation lots of steps may actually be needed for both roles. The source account role may require checking that there is enough balance, may need to flag that the source is suddenly gone into overdraft, may trigger the sending of a fine, etc. The destination role may trigger a further interaction, such as a transfer of money to a savings account if a certain balance has been achieved. One person in the audience came up with The Matrix analogy: Objects are people, roles are capabilities that the humans can load into their brains that they need for a mission, such as Kung Fu. Maybe it is more Dollhouse than The Matrix.

• Context = Use-Cases: The context is a use-case. It is all about selecting objects that are part of the use-case and injecting the roles that these objects need to play. The context is also about explicitly connecting these objects through interactions. In the case of the money transfer use-case, the context object would store the amount transferred, find the source and destination account objects by their IDs and inject the source and destination roles into the objects.

This means that it is suddenly much easier to translate the mental model of the user into code: there is a clear mapping between both worlds. This makes it easier to test whether the code is correct.

A number of other good things happen too – really by design: Use-cases have a direct representration in code. If you got your use-case right, your code will be right.  The same is true for interactions, which are pure algorithm presented in small pieces of code that the human mind can understand and review. So altogether it will be easier to review and test the the code.

Of course there are problems …

However, all is not well. Not all OO languages have the capabilites to implement the DCI pattern well. You need to be able to inject code into existing classes: try doing this in Java. In C++ it is possible using templates, but only in a static manner. The devil is really in the detail.

Not all questions around DCI are resolved. For example: How does DCI work in a multi-threaded world? How can you introduce it into a non-DCI code-base? Does it really work in large scale applications? DCI is fairly new, so new that there is no Wikipedia article yet. On the other hand, this means there is scope to shape this movement and get involved. Check out the DCI site fore more detail and forum for some interesting discussions.

Nevertheless it was an interesting series of talks and attracted a big and excited crowd. Trygve introduced the problem and topic, James explained the detail and Rickard showed an example using an extension to Java. Given that we have a large C++ code base, I thought there is merit in sharing these ideas and kicking off a discussion.