Difficult OO concepts: type, class and object

I have just read an article from a Finnish magazine about Scala. It contained confusing claims about OO implementation with OO languages. It have come across this argumentation earlier but it still remains as mystic to me as on previous occasions. I am convinced that it is a complete misunderstanding. The line of thought is combining OO- programming and functional programming in a way that is not even in theory possible. Similar lines of argumentation were earlier present wit OO- programming languages and SOA and this of course proved to be false too.

I must start once again from the very beginning. When we create an operational business application the domain model is the core of that. The business layer is typically only 10 – 20 % of the whole application code but the importance of it is in most cases 80 – 90 %. The implementation of this business layer is almost automatic generation of the OO domain model.

The domain object web is a many to one mapping from reality to the model. This means that the objects in the business layer has their corresponding objects in reality. This way ever real object and its corresponding model object has an identity and thus a life cycle. This means that all business object in the implementation are born and die according their counterparts in reality.

Let’s expand from object web to analysis and domain class model. Classes are classification instrument for real objects. Class gives a simplification of a category of real object. Is kind of minim commonality among objects that belong to this category. This way the classification gives an object a type.

Now when we have finalized our abstract analysis of reality and we have created the domain class model as an highest level abstraction and a few object level fragments (called collaboration diagrams), the implementation reverses the order and start from classes in the implementing code.

Sometimes when people come from strong programming background and the modelling and reality for application mapping is not that strongly emphasized, they loose this visibility. Somehow the techniques of language structure confuses these persons. This way the crucial fundamental of an identity gets lost. This way someone quite sincerely uses complex number as an example of an object. The fact is that it is NOT an object! In an OO- programming language we use class definition for two different purposes:

1) to describe object type (classification) or

2) to create “object like” structures that are NOT object!

The second choice is actually a misuse! It is quite convenient to use this structure in this way and it is quite OK, if the users understands these two aspects and don’t confuse them.

Day is a type for an event but it is not an object. Every technical event object requires at least one binding association to some real object to become a real object! We can of course technically create “an day-object”: myDay = new Day(); . But myDay is not an object because it doesn’t have an identity and there is no real thing that this artefact maps to. The only thing that can be said about this thing is that it is “an object-like structure”. This means that it has private attributes and public methods, but it still is not an object! The time semi object is transformed into a real object when it is associated with a real object. This gives the time object indirectly an identity. After this an event is not any more a template but a real event (in past, present or future). Then it is identifiable and unique in the universe.

A third way of misuse is to create a class and on object that has only behaviour. Here the confusion steams from something like sub function or a procedure. This is a fatal confusion and indicates that the designer has not cached up the object idea at all. Disconnecting a functionality from its context will definitely destroy the whole OO paradigm and its benefits.

Eric Evans in his book Domain-Driven Design in the chapter Services warn about this thing in the beginning of the chapter, but surprisingly he then accepts “Manager” or “Control” type of classes. My strong opinion has always been that this is a fatal mistake. Everywhere that I have seen this done it has lead to complete procedural programming with OO- language and this has always let to dome sort of disaster. One of the reason explaining Evans position is the week separation of implementation layers: application and domain. For instance value-objects belong to the realm application implementation. There are quite a lot of trick that we still have to do during implementation – sometimes for instance value-objects. The reason behind this is the extremely poor implementation platforms. Such problems should be take care of in the platform “operating system layer”, but this is not the case today far from it!