Not Your Grandfather’s OO: Data Context Interaction

Last week I was at Øredev 2009 giving a talk about what we 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, Web Development.

One topic which stuck out for me was a series of talks about a new programming model called Data Context Interaction, 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 the talk by Trygve Reenskaug introducing the topic, was that in many cases OO as 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 todays 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-cases 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 DCI the 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 ecapsulate 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.

 

ØRedev 2009: Towards an open development culture

Yesterday, at ØRdev I gave a presentation on what the Symbian Foundation has learned since it was created. Despite the fact that all the other talks in the Mobile 2.0 track were about the iPhone the talk was well attended. I wanted to share the slides.

Towards An Open Development Culture V1.0

View more presentations from larskurth (been struggling with embedding flash)

The conference has been great so far: was particularly captivated by a talk this morning on the Data Context Interaction architecture, outlining a new vision for object oriented programming. Programming languages and paradigms have always been a topic I was passionate about … will share my thoughts over the weekend. Still two more talks on that topic AND on experiences made building an Android phone.

Watch this space.

To Blog, or Not to Blog

I have been thinking long and hard whether to create my own blog, or to mainly publish stories on the Symbian Blog. After some thinking, I decided to create my own for a number of reasons. I will continue to write articles on the Symbian Blog.

One of my key challenges in the last few weeks has been to get Symbian Package Owners and Committers to create their own blogs, and to regularly publish stories of what they do, what is hapenning in their domain and their package. Blogging and other using other on-line media are a keytool in building open source communities. To make this easier, the Symbian Foundation (my employer) created the Planet Symbian blog aggregator.

As I found out the hard way, getting engineers who are not used to blogging and come from a proprietary background to blog, is not that easy. So I decided to take a lead and create my own blog. After all, I can’t ask them to blog regulalry, if I don’t.

The other reason, is that much of what I have learned in the last 6 months may be of use to other open source communities. I always knew that, but it never really clicked. Apart from preparing for SEE 2009, I spent much of the last 2 weeks working on a presentation on showing what Symbian has learned since it was created in March. That helped me realize, that there is quite a bit of stuff that others can learn from the Symbian journey. If you are at  Øredev 2009 this week, come and see my talk. If not, I will post it on here and on developer.symbian.org afterwards.

That’s why I created this blog. Hopefully I will manage to regularly publish stories about activities at work, things that move me, staff I learned and what is happening in the Symbian community.  I will continue to write articles on the Symbian Blog, but some stories will better fit here.

Oh, and do let me know if what I write is bollocks (ah, sorry “poor quality” or “useless”) such that I can improve.

About Me

My job is to help existing contributors to the Symbian Foundation, in particular package owners and committers, to be effective and get value out of being contributors. This requires building and maintaining close relationships with our contributors, understanding their needs and act as a faciliator and mentor to identify common challenges and propose solutions. I typically introduce potential open source contributors into the community and work with them to get established.

Within the foundation, I act as advocate for contributors. This means that I identify potential barriers and problems in processes, infrastructure, etc. by working with the community and will work with foundation staff and other stake-holders to resolve these. I also act as the voice of the contributor community, wherever else appropriate.

My Interests

I thought I’d say a bit about myself: I have always been a somewhat complex personality, which is reflected in the many different interests and passions that I cultivate. From my early teens I have been an avid plant lover. I am particularly fascinated by orchids and carnivorous plants, and have built a rather large collection of plants from all over the world. My love for plants extended into a passion for travel and for gardening. Quite often I travel to see plants grow in their native habitat (such as the Tepuis in the Gran Sabana, or the Amazon rainforest). You may ask, why I did not become a botanist or run a nursery: maths and computing have been another passion of mine since I was at school, and it seemed a much wiser choice to build a career around these than building a career around gardening.

I have always loved reading and literature and films. I was fascinated by made-up worlds of science fiction and fantasy from early on and still get my weekly dose of Perry Rhodan, the oldes science fiction series of the world. A pity it was never translated into English. When I moved to London many years ago, I discovered the arts and theatre. Not something where there was much to disover in the town where I grew up.

Once I got over my geeky phase in my teens, where it was near impossible to get me away from my Amiga computer, I discovered that I was actually a very social person. Today I spend a lot of time with my friends and talking to colleagues.