Echoes from the golden age of OO

OO-languages rules the programming language domain sovereignly. OOA method is quite evidently far the best way to begin application development process. How ever this fact was somehow lost in the middle of 2000’s.

Here is a short a retrospective of application analysis development methodologies from 1980 onwards. Behind this development and the case of it is the ultra rapid development of computers. Computers are latest category of technic evolutions and its rate of change has been phenomenal. Following this exponential technical development and understanding the development as a howle is extremely difficult because all the development in the past seems quite minimal compared to recent. So it is very difficult to give real credit to those steps in past as they seems so tiny compared to later ones.One example of this development is the following: IBM PC publisti in 1980 had a processor with 4,5 MHz clock rate and today the PC:s clock rates are around 2 GHz  ( =2000 MHz). This is about 500 time the original speed. This enormous change has very significant impact on the methods of working.

The development took us from relational databases to object-orientation. In late 1970’s Allan Kay and his colleagues created the first object-oriented language Smalltalk in Xerox’s development center Park Place. The language was commercialized in early 1980’s. This created development was continued with the rise of Object-Oriented Analysis. In this approach the world was viewed in terms of object and their relations.This phase started at early 1990’s. Among the first pioneers were Grady Booch, Peter Coad, Adele Goldberg and Jim Rumbaugh just to name a few.

I run into OOA in October 1989 in Peter Coad’s 2 day training in Stockholm. This occasion changed the course of my professional life. After half day’s lecture I realized that these people had understood something fundamentally important. Something that solves easily most of the acute application problems and this first impression proved to be true.

A couple years went and then we acquired the only solid commercial Smalltalk language from ParcPlace. We started to study OO-programming with Smalltalk. It wasn’t quite easy because it was very difficult to get any training, so the advance was based on selfstude.

When we developed our Smalltalk I continue to study OOA. To the end of 1990’s when I had  stated to work in software house and I started to give trainings on OOA. During the first half of 2000 decade I created a lot of AAO-models and develop the process to more abstract and agile direction.


My ADDD ( Abstract Domain Driven Development )

The OOA/OOD mature during first half of 1990’s. ( see: ) One of the latest and best book on this field is Grady Boosh’s Object Solution (1996). This is more or less a testament and of that whole field.

As a whole this was one of the greatest achievement in the history of computing. In spite of this I saw there a significant weakness that was revealed be the efforts to use this brand new methodology. That is the lack of separation of concerns. This methodology analysed application as a whole. This will increase complexity enormously. When OO-application development method on the other hand emphasised the 3-tier architecture where the domain and the application views were considered as separate layer. This led my to experiment to do the separation wright at the beginning of the analysis. That is why I called my method Domain Analysis. The difference was considering the domain – the interesting part of reality – as the object of the analysis. This way the application part was completely dropped. Then the second step is to create the object model of the application and this model was connected to the domain model by messages – as object always do. This allowed the domain analysis – and also the implementation – to be done without any knowledge. This meant a significant reduction of the overall complexity. This also allowed several application layer designs and implementation for instance for separate usages or implementation technologies.


Situation today

I wrote my my blog a tutorial covering ADDD : IT-Dinosaurus in WordPress from 2009 to 2014  I got a considerable amount of readers during those years. The peak number of visitor came between 2010 and 2014. One notable thing is also that most visitors came from India, US and Canada! Very surprising is the fact that there was still in 2016 the number of visitor was still 4500 and ranking of the countries was Canada, US and India.

In mid 1990’s I ( and also Grady Booch) thought that OOA/OOD/OOP would by the standard most common way to develop application, but it didn’t turn out that way. In early 2000’s the big database companies were afraid of losing their businesses to OO-databases and they started a big campaign to stop OOA usage and they came out with SOA, which was devastating for software industry development and took us backwards several step to history, but the old dinosauruses – the relational databases were able to maintain the market shares.

The thing that surprises me today is the amount of visitor to my old blog. It shows me that there are still a lot of enlightened persons in this field, that has rediscovered the true value and meaning of OO today.

Echoes from the golden age of OO

The state of OO -development in 2017

I have started this blog on OO application development in 2009 and posted the last post on this issue in 2014.

The core of my approach is centered on abstract domain OO – model. To created these models one needs deep understanding of the underling theoretical concept. This can not be achieved just following a set of rules. The divider is the abstraction level and thus the model size. If the abstraction level is too high the model has no value. It dos not promote the understanding of the domain. If the abstraction level is too low, it is even worse because too much detail prevent the possibility to separate important from unimportant and the just isn’t a way to return. So too detail model poisons the whole process.

A just right model create a great opportunity not just a good and flexible domain implementation but also for user interface part of the application, because early separation of concerns will dramatically reduce complexity of both sides.

I started to write the posts at late 2009. It has gathered 48 000 hits all together. I have posted my last OO article early 2014. The OO did not concur the world as I and Gready Booch predicted around 1995. For this reason I am gladly surprised the current hits at my blog currently. For most of the time my readers came from US, Canada and India, but almost the whole world was covered.

I have retired 3 years ago and I don’t have a hands on touch in the current development trends. My current surprise is the activity around my blog in 2015 and 2016 there were about 4300 views and 2000 visitor yearly and most visitor came from US, Canada and India. Even this year there has been about 1000 views and 580 visitor from the same countries. I am both happy and honored about this.

I would be curious to know the motives for these visits and the current state of OO development in the field.

Objects before behavior – the most fundamental OO concept.

There has been for some time now at least some debate about functional languages. These are declarative in nature. In these the actual processing is defined by describing the logical predicate that the result must fulfill. Thus this brings the computing near mathematics. I have seen many times attempt to declare that computing is mathematics. Most probably one can do mathematics with computers but computing (ie. programming of application) is very far from any mathematics.

My viewpoint to computing is business operation control. In other words the company’s application portfolio reflects the state on the reality within the company and gives to the worker of the company a possibility to monitor and manage the business actions. In this domain – that actually is the great majority of all IT of companies – the amount of complex computing is non-existent. There are also some complex calculation done somewhere but I am not familiar with these but here we are talking about complex calculators.

When I teach the basics of OOA, I will start with looking how we perceive the world. Well here is the core of that:

The reality, the whole world consist purely of material things that we can generally call “objects”. ( see. The first few page of Ludvig Wittgenstein: “Tractatus Logico-Philosoficus”). So everything is object and there are layer of objects within objects. This way the concept is highly abstracted and gives us the intersection of what is the smallest common denominator in the reality. What is the common thing in all objects? The answer is uniqueness of objects. We all are unique this is materialized by a common attribute: ID. To the uniqueness is loosely connected the fact that there is no object in the whole universe that is eternal. So every single object is bound by the time. The consequence of this is the every object shares two attributes: time of birth and time death. This way every object is created and destroyed in one way or an other. In an OO model these basic facts are reflected in class model. A life of on object is a continuum of state transitions – the states that are realized as values of that objects attributes.

Now we get to the issue. All action or behavior is always performed by someone or something. So every action has a subject – ie. someone behind the action – an actor.

OO- paradigm uses this fact very effectively. In OO there are no unbound action, function or other behavior. The realty is modeled by two types of behavior: internal and external. Internal is behavior that a single object produces and external behavior can be called collaboration. Well of course this requires that a fight of what ever type between objects is one kind of “collaboration”. Collaboration is objects internal action and messaging between objects.

SO when we try to mirror some part of local reality the minim complexity is achieved with this kind of one–to-one mapping (or homomorphism if you want to put it into mathematical terms). In this kind of implementation every function is implemented at most once. This is never the case if all the behavior is not bound in objects. Of course you can break this role also with object if you want, but it is easier to detect to be avoided. This yields absolute minim complexity solutions within von-Neumann machines.

On other finding after creating a few of these is that the business method within the business object are almost without an exception stupidly simple. If one is looking for really complex behavior it includes learning and it can not be ever achieved with von-Neumann machines but needs a neuron based architecture ( see:–0&#video )

The three gems of software development

Buddhists talk about Three Gems:

  • Buddha: the enlighten one
  • Dhamma: teaching
  • Sangha: literally means ‘community’ or ‘assembly.’

Here are similar thing for Object- Orientation. The difference is the later are strictly non religious, but there in spite of this some similarity and that is the belief in one’s own case. These are:

  • The paradigm
  • The abstract business model
  • The agile incremental 3-tier application development

The paradigm: To know and understand the OO- principles and also to understand it paradigmatic nature. This means that the world is perceived abstractly as a set of objects such that:
* all of them have two aspects: structure ans behavior

* they can collaborate with ease other

* there is no other kind of action possible in the world

The abstract business model: The development has to be started with creating an abstract domain model from scratch. Of cause one can use for this something like the business line models as I have presented here as a starting point. But even then every class have to be evaluated and checked that it is defined to this company and describes the current reality correctly. The model have to have all essential business behavior embedded in the model. The most important aspects in the model are objectified events, there behavior and object associations.

The agile incremental 3-tier application development: To succeed in this phase is crucial.

To continue this line of simplicity the architectural structure is the final cornerstone of this application. The maxim simplicity is achieved when the implementation keeps the three aspect: 1) application functionality, 2) domain functionality and 3) object persistence as separate as possible. Here a must is that domain objects have no functional references anywhere outside the domain itself. There are minimal references from application layer to into the domain. And the domain objects should have one references each to outside service that provide the persistence. The optimal solution would be such that the object virtual machine provides that service automatically into an object database.

This is the final phase to really deliver the concrete application. Next important aspect is to create the application incrementally and iteratively. One mustunderstand that the abstract domain model from previous steps is more of a starting point than end result which will grow in size during the development. On the other hand it is vitally important the first model is relatively small and thus will clearly describe the most important structures and behavior. This means that this model should have most of the structures present ie. most classes and associations are present but major part of attributes can still be lacking.

Done this way yield to minim solution thus minim amount of work and this enables indirectly maxim quality through simplicity.

The most is achieved when the model covers all activities of the company and the application layer is a comprehensive operation management and control of the company ( like ERPs today)

Why process models and SOA are steps backwards in development of computing

I was about to write of software packages and their integration. But just by go incidence I run into JBoss ESB and I got very annoyed. Here I stumbled in SOA and its heirs again. Grady Booch ( even as he was working for IBM which at lest at that time was a strong supporter of this “new” SOA approach) got totally pissed off with this SOA and wrote an article SOA ( Sneak Oil Architecture ) and accused the whole thing being complete bluff. So I just must once more return to the very roots of OO.


The real step from procedural to OO was the the encapsulation of behavior. The big invention was to tie up all behavior into objects. This meas that the structure comes FIRST and the object will limit and guideline this behavior. This means that ALL the behavior is boxed inside these objects and the total behavior is result of objects’ internal behavior ( ie. methods) and the collaboration between objects.


When OO started to technically mature and become possible to implement it in Java, the big legacy code owners and people around it got upset and where afraid that they become obsolete. This was why some powerful groups started the manipulation of language and started to speak about services instead of methods. In the same situation the idea of object was semantically changed to component. With these tricks the whole OO- paradigm was diluted away. After this a service could be any colossal old COBOL application!


Along this line of thought the SOA with “orchestration” was born. This orchestration was previously call “main program” and the services where call subprograms. In this process class-model was degenerated to entity model that we did in ancient time for relational databases. So the reason where the big relational DB-vendors ( such as IBM & Oracle and later also Microsoft) had a huge steak to be concerned of. In early days of OO we used to talk about “impedance mismatch” between object and relational. This created a considerable threat for the whole profitable DB- business. Finally this wiped out the whole OO-paradigm.


In this way we (at least big part of us) were taken backwards in time at least for a decade or even more. The truth remains that the complexity of this process or use case approach leads at lest tenfold complexity of the result and the trouble is that the growth of that complexity is unavoidable when the domain is something else that totally trivial.


In my next post I will write about the difficulties that rice from trying to assemble operation management system with package software and “integration”.

Domain model for person’s social life

This is a domain model for SoMe type of applications. In the center of this model is quite obviously class Person. This differ from typical business model because it is much harder to decide what to include and what to exclude. Also the level of abstraction need consideration. Here I have stayed on a pretty high abstraction level to give my readers most clear picture of the most essential structures.

There are a few very concrete entity classes: Person, Place and Building ( which can be a subclass of place). Then there is also a more abstract entity class Organization, which can be for instance a company in which one works at or a club where one belongs to. At first the class Place looks very innocent, but after consideration one find out that it is a tricky one. Basically it is a geographical spot or an area. How ever it must be able to handle well-defined distinct areas like an named city: Helsinki of a square: Trafalgar  square and on the other hand it must cope with more fuzzy are like southern Helsinki  of western Kent.

Then we have these most essential events around the person. This list start with simple things like where person is or is heading. At the other end of that spectrum are events like activity and participation.

Here is the class diagram:


The human social networks are all take care with event call relationship. I have added here also a classifying description type class Circle.

Here are an object diagram and a collaboration diagrams. The object diagram is a case with part of John’s social network. The other one have two short collaborations where Jim creates an activity and buyes a concert ticket.

Social network (object diagram)

Collaboration to create an activity and buying an ticket.








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!