Stubborn confusion with behavior

All the way from the early days of OOA (late 80’s and early 90’s ) it was crystal clear the description of procedural  and object behavior are strikingly different.  There is no right or wrong, they just are the same thing from completely different viewpoints. They are orthogonal abstraction of the same thing.

The most significant thing that created object paradigm was just this difference. This is a paradigm issue and thus the difference has a strong antagonistic nature. This means that you must choose and there is now way of mixing these together.

The big step in deeper understanding simulation modeling was that object collaboration yield to a magnitude simpler model than the corresponding procedural one.

This is a simple fact of reality and it can never change. This means that it is logically impossible that ever anywhere could come any new information that could change this.

Somehow most of IT community lost this crown gemstone of OO. First came use cases as Ivar Jacobsson introduced them. He had actually good intentions but he was misinterpreted and his idea was turned upside down. Then came components and after this activity diagrams. Now the newest names for procedural description are processes and SOA!

I saw somewhere an article where the writer praised “the blessing” of the fact that we “get rid of spreading the behavior and we can collect that all in one place”. This very thing was just the reason or drawback which was cured be bringing the structure and behavior together and distribute responsibilities between object. In this way we got two layers of behavior with first layer encapsulated within the objects. Then the second layer is the collaborations between objects.

We can actually prove this reduction of complexity today with the huge help from microbiologist Stuart Kauffman. Our practical experience tells us that the simplification ratio in average case is 1: 10.      

My motto.: The Use Cases (by whatever name) are evil so retreat  to collaboration.

 

Unambiguous language and DDD

The real purpose of OO-modeling is  – as modeling as whole – to create abstract simulation of the world. The closer the model follows the structures of reality and the corresponding behavior of the associated parts the better the model simulates reality.

For this reason it is vitally important that all the concepts are clearly define and unambiguous.

I have been developing Smalltalk and Java application since 1994. All of these have been built starting from scratch an abstract domain model and finally implementing this as the middle tier of and application. In my experience the most crucial thing here is right model of the world itself. This means that the business understanding is crystallized in the model. This means that the understanding, the language it is expressed is equivalent with the model. These are the same thing. Thus you don’t actually need a separate glossary because your class and attribute definitions is that glossary!

Yes! This is the most crucial thing of all. When this is right everything else goes smoothly if this is wrong there is very little to be done to correct the situation. More of this at my web-site and of course in Grady Booch excellent book:  Object Solutions ISBN:

Finally a quote from that book:

 The center of gravity of an object-oriented information system should be its domain model.

·         Get this model right, and your task will be much easier.

·         Get this model wrong, and abandon all hope.