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:

http://www2.dac.com/events/videoarchive.aspx?confid=122&filter=keynote&id=122-120–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!

ADDD is future!

Within at least 10 years I have not seen a slightest indication that there would be anything wrong with my ADDD approach on the contrary ever time it has been tried everything in the method has been proved to be working. Almost the opposite is true with many people and organizations!

I was fired by Tieto software house, because they did not find me any work. The reasons for this are
1. they don’t believe in object paradigm but processes and orchestrations.
2. they don’t want to work in lean and agile way, but they believe in detailed planning and waterfall.
3. they don’t believe in custom made but packages.
4. they don’t believe in professional teams but resource pools.
5. they don’t believe professional operating team (surgeon team) but distributed offshore development.

These differences drifted us apart. This is not just between me and one big software house. This is a global phenomena. The change here between the parties is a paradigm sift. Paradigm sifts are really big thing to do and to happen! Peter Coad in early 1990’s used as an example the wrist watch industry. When Japanese developed and electrical watch based on oscillating quarts crystal. Swiss had a flourishing watch industry base on old paradigm: mechanical machinery. These people from old paradigm were laughing at Japanese at their “toy” watches until their own industry collapsed totally! The same story repeats over and over again in our resent history: car production in UK or in US and Japan, home electronics in Germany and Japan, camera production in Germany and Japan, national flag carrier airlines and low cost airlines all over the world etc. Here the basic physics apply: the bigger the old paradigm activity is the more energy is required for the new paradigm activity to overthrow the old, but also the bigger the old is the faster the collapse will be after it has started.

The old paradigm will materialized in organizational structures. The bigger the organizations grow the more internal friction it will generate. This means that when a organization is created and its functional basic principles are set it is extremely difficult to change that fundamentally. The first big obstacles are the peoples’ skills. As the persons are selected by their their skills to suite the initial functions it is next to impossible to manage and carry out a process where the skill set is changed for most of the persons in the organization. This would require almost duple personnel if these people are to perform both their daily tasks and at the same time learn completely new skills. The next big question is do these people really learn required new skills at all! In short if this sometimes works it will be a miracle.

The most crucial part of this chain is of course the customer for whom the application is intended to. This current situation continues as long a the ability to secure their vital interests lacks almost totally from the client organizations. Of course this doesn’t change quickly. I have no idea how long this is actually going to take but anyhow it is required prerequisite for any progress! I can easily understand the responsible management when they are facing a situation, where they have a terrifying legacy backlog, ongoing critical production usage of the old system.

My prediction is that the change is going to start from medium size innovative modern companies. After the new far better production methods have been driven into at least some strong professional teams that has really internalize the fundamentals and the work processes thoroughly the last and then the customer that really wants the best and is not content when they only get something. This kind of customer must understand the underline principles at its high management, check the team’s quality and then trust it and fully commit to really work together to reach the results. A few such hits will finally start an avalanche.