Rickard Oberg is popular among Java developers. He has given seminars at all main Java conferences world wide. He worked as an architect at JBoss and other popular OpenSource Java frameworks, and wrote a book on RMI. In recent years, he has become famous as an Aspect Oriented Programming (AOP) crusader. He has worked with bleeding edge AOP in a portal product that has become a great commercial success, and is currently working on Qi4j at Jayway. Rickard is a DZone MVB and is not an employee of DZone and has posted 16 posts at DZone. You can read more from them at their website. View Full User Profile

Contexts Are the New Objects

03.30.2010
| 5052 views |
  • submit to reddit

When we went from procedural programming to object-oriented programming, by realizing that we could remove the "object pointer" as the first argument to a procedure, and instead went to a model where methods are invoked on objects with identity, it fundamentally transformed our ability to structure and reason about software. Now, with the introduction of the DCI paradigm, I think that a similar change is possible, by realizing that DCI contexts are to stateless services what objects were to procedures.

To understand this you have to start with understanding where DCI fits into a typical enterprise architecture, because by doing so you can compare with other ways of doing the same thing. The basic idea of DCI is to select a number of objects into a Context, and then perform Interactions on it. The Interactions represent the developers mental model of the software, and as such are a good way to implement usecases.

So if you don't use DCI, how would you do the same thing today? The typical approach is to use stateless services, where each method takes a number of parameters, some of which are object identifiers, and some of which are "real" parameters, like strings and ints, that you use to handle the variation of what the method can do. In other words, DCI goes mainly into the application layer of a system.

At this point, let's make a comparison. As mentioned, with the transition from procedural to OO we went from:

procedure(id,param1,param2)

to

object<id>.method(param1,param2)

And with DCI we are now going from:

service.method(id1,id2,id3,param1,param2)

to

context<id1,id2,id3>.interaction(param1,param2)

Can you see the resemblance in approach? By explicitly introducing an identity, but this time of a set of objects rather than just a single object, we can simplify our interactions in the same way that object methods simplified procedures. We no longer have to do the lookups of the objects, validate that they are ok, validate their relationships, and so on. Instead all of that is done in the construction of the Context (much like how a constructor initializes an object), so that the Interactions can focus on what to do with it. My previous post on DCI shows some example code for this, and I can see that in my own codebase the structure and implementation has been radically simplified because of it. It was made even more clear since we started with a non-DCI solution and then refactored it once the realization hit us. Tears were shed I can tell you once we saw how much simpler everything became.There is probably more to be said about this, but the basic idea is simple enough and powerful enough to be just what I presented above: I think that the contexts in DCI will replace stateless services, just as objects replaced procedures in its time. And it is going to be simplifying and clarifying our software radically. For those of you who have had the question "What should I use DCI for?", this is it.

From http://www.jroller.com/rickard/entry/contexts_are_the_new_objects

Published at DZone with permission of Rickard Oberg, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Ant Kutschera replied on Thu, 2010/09/30 - 4:57pm

Hi Rickard,

I've spent some time looking into DCI, but something still doesn't make complete sense to me... A "role" is where you capture the algorithm, but:

  a) why does it need to be injected into the data object? I presume purely so that it has access to the data fields and state methods of that data object?

  b) why can't you implement a role/context as a SLSB?

The point of DCI is to stop system behaviour getting fragmented as happens in pure OO solutions.  But the point of a SLSB is to act as a stateless service which operates on objects that you pass to it, and handle the interactions between those objects.

I'm coming from an SOA perspective - not SOA as in web services, rather SOA as an architectural paradigm for building applications, if you see what I mean (service hierarchies, EJBs/Spring/etc)?  We have been capturing system behaviour in services for nearly a decade now.  If you create the services to reflect use cases (rather than services reflecting parts of the domain model), viola, all the problems which DCI are attempting to solve, are solved with services.

The advantage of services, over DCI?  Simplicity for starters, not to mention no need for traits or something like Qi4J. And then other dimensions like cross cutting concerns (transactions, security, etc) which a container can handle (well in Java EE anyway), or resource management.  DCI doesn't address the issue that without a container, these other two dimensions muddy the waters when attempting to review code, or just read it to work out what it does.  Without a container the code gets bloated with technical stuff, rather than just containing business stuff.

I hope you post a reply, because I really am struggling to get why DCI is better. 

Thanks!

Ant

PS I'm working on a white paper about this, and have taken the banking example which Jim Coplien used and implemented it as OO and SOA, to compare the two. I still need to implement it as DCI, so that I can compare all three :-)

Rehman Khan replied on Sat, 2012/02/25 - 4:43am

"So we let the compiler inject the object pointer as the first argument instead. It's just sugar and the "this" pointer can be just as easily introduced in C, a non-OO language. "

Even polymorphism is just a syntaxic sugar for function pointers, nothing more.

If you think of it, there is nothing new in any language that is not feasible in a turring machine.

It just bring it to the mainstraim and make it easier to use.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.