DCI Is Not Against Inheritance

2011-09-06T15:06:00.000+02:00

Recently I've been discussing an implementation, where object inheritance was used for one of models. The DCI paradigm was applied to implement this part of the system. Some opinions were that adding inheritance breaks DCI conventions. To me this is misunderstanding of DCI. Inheritance applied to data model can not only co-exist with DCI, but actually can help to create a better domain.

What is DCI?

Data, Context, Interactions is a programming paradigm invented by Trygve Reenskaug. DCI was created to improve code readability and maintainability, compared to the traditional OOP. The basic idea behind DCI is to split Data (what object is) from Interactions (what object does). These interactions or behaviours are extracted to separate Role objects. Roles are then assigned to data objects at runtime, only when required within given Context.

Here is an example of DCI implementation in Ruby:

The created person object by default only describes a data model - what it is. By default this object is not capable of doing much more than reporting it's state.

In a FootballGameContext, the person object gains a new football player role and is able to run and kick_ball. In a Shop context, the same person object doesn't act as a football player anymore, but becomes a buyer.

To understand DCI well, I suggest starting with this wikipedia article and if you have enough time, it's worth reading the artima article on DCI

I find DCI a very promising paradigm to address some of the issues with OOP, but I'm definitely not an advocate yet. I haven't seen any big enough application written using this paradigm. I have no proof that DCI leads to cleaner and more readable code, than the traditional OOP with i.e. mixins or Design Patterns. Although it's worth investigating, it's still an immature paradigm and it's lacking good patterns to follow. One of the main problems, mentioned in one of Andrzej Krzywda's articles on DCI in Ruby, is the ambiguity of when and how to define a Context.

DCI And Inheritance

Inheritance is one of the base OOP techniques. It is often a perfect way to describe "is-a" relationships in a data model. There is a very good answer on StackOverflow, describing when to prefer inheritance over composition. Inheritance can lead to unmaintainable code when abused, hence it is considered evil in some circles of programmers.

There are many other techniques which can be used as alternatives to inheritance, like Mixins, Strategy Pattern or Adapter Pattern. I don't want to argue whether inheritance is evil or if other techniques are better. In my experience, for each of these techniques there are scenarios where they fit best, including inheritance.

One of the issues that DCI addresses, is overusing inheritance to give objects additional behaviours. In the code example I gave earlier, FootballPlayer would become a subclass of a Person.

This works just fine if a person object is used only as a FootballPlayer. Problems start when the same person object is also expected to buy in a shop. We need to give it Buyer behaviour. Using only inheritance we would either have to create some kind of FootballPlayingBuyer using multiple inheritance or make Buyer a subclass of FootballPlayer. You can imagine what happens is if we add more responsibilities.

Although these problems can be solved in many ways, i.e. using mixins, the DCI paradigm guarantees these problems will never occur. In DCI, every behaviour (Role) has to be encapsulated in a separate object and is only added when context requires. DCI is indeed against inheritance - inheritance of behaviours.

DCI Doesn't Affect Data Model

DCI separates data model from behaviour, but it doesn't set any rules on how the data model should be designed. The following example shows how DCI and inheritance can coexist together.

Ship and Airplane are two types of a Vehicle and can always be used where Vehicle object can be used. Subclassing seems to be a natural choice here. Both objects are still just dumb state containers and they get required behaviours only when needed.

My bottom line is that DCI not only depends on well designed data model, but it actually helps to design it, by separating the behaviour and allowing programmer to focus on a data model alone.
Inheritance can be sometimes the best fit to describe some parts of a data model and can help application to reflect user's mental model, which is one of DCI goals.

Bartosz Blimke's Blog

DCI Is Not Against Inheritance

What is DCI?

DCI And Inheritance

DCI Doesn't Affect Data Model