From the Mist

The essence of OO can be summarised in two statements:

1. Active/passive rule
2. Demand-chain cooperation

This article introduces these two important and undervalued patterns.

The Active/Passive rule

This rule can be summarised as follows:

“Objects that are active in the real world are modelled as passive, and vice-versa.”

Rob Vens

This is only a trick. Many modellers have stated that the object-oriented model is a representation of the real world. This is true, but not entirely. And the model differs from the real world in exactly these two essential characteristics. The active/passive rule turns behaviour around.

There is a strong synergy between this rule and the next, because the way we should couple objects (or services for that matter) is based on first modelling objects active/passive, and then thinking about which responsibilities we would like to delegate to them. This way service interfaces are created that realise exactly what we want: loosely coupled, maximally cohesive systems.

An important rule is that “external” objects, usually modelled as actors, are modelled inside the system as normal (but passive) objects. This way it is clear and unambiguous what entry points there are for the external world into the software replica of this world. Modelling these objects as passive avoids the pitfall of modelling complex objects that are hard to understand and even harder to modify. All aspects of these complex objects in the real world are externalised into active objects. An example: a person uses a pencil. In the real world the person is active, the pencil is passive. In the software replica model we turn things around: the person becomes passive, and almost void of complexity. The pencil becomes active, and all behaviour corresponding to writing is delegated out of the person into the pencil. And even then, if the pencil becomes too complex, we use the rule of delegating responsibilities to make each of the active objects so simple that only one responsibility remains – all else is delegated away into other active objects. The resulting network of cooperating objects is complex as a whole, but simple when zooming in. The net result is a network of objects that is easy to manage.

The demand-chain cooperation

This rule can be summarised as follows:

“To fulfil their goal in life, objects search for other objects to delegate their responsibilities to by inverting time, and starting their search at the end: the final purpose of their cooperation.”

Again, this is only a trick. There is no other way to reach the goal of loosely coupled objects, which cooperate to accomplish complex tasks, which can scale in time to become more and more complex. Objects perform tasks as a result of the responsibility delegated to them. When the task has been designed following a supply-chain process, this task is too tightly coupled to the requestor or delegator. The process cannot change in time to adapt to the changing business, but has been used as the criterion on which to base the objects’ responsibilities and behaviour. The process has been cemented in tightly coupled objects. The demand-chain rule turns time around.

The way messages are used to request objects to perform a service is widely misunderstood. As an article Service Oriented Architectures vs. Distributed Object Technologies (not available anymore, sorry) tried to argue, many people have understood message between objects as something more or less similar to function calls: an invocation of a method on an object. As Dan Ingalls already in 1981 in the famous August 1981 issue of Byte Magazine tried to explain¹, objects sending messages do something quite different: they politely request the receiver to perform a service. The receiver then decides if, how, what and when to do that. Messages as they should be modeled in object-oriented languages do not differ from the way messages are to be modeled in service oriented architectures. The argument, often repeated, that service invocation is “completely different” from object-oriented message passing, is false for properly modeled object-oriented models.

Modern developments in supply chain management clearly emphasize the advantages of demand chain processes for just-in-time inventories, flexible processes etc. This is exactly what we are talking about here.

Both rules are deceptively simple, and both rules are usually completely overlooked in publications about object orientation.

There are many more rules to good object-oriented modelling, to name a few:

1. Objects are simple. Their purpose and behaviour should be understandable within minutes.
2. Objects abhor responsibilities. Designers wishing to place a responsibility with an object, are met with strong refusal, especially if the object already has one responsibility.
3. Objects represent behaviour, in particular responsibilities delegated to them. They do not represent data or business rules.
4. Business rules exist. In object-oriented models they are contained and managed by objects in a way that effectively encapsulates them.

In future articles I expect to come back to many of them and many new ones. These rules are just a few, as an example. In fact there are many more, even several hundreds. No experienced modeller has all these rules in his or her consciousness, but on the subconscious level they work without pause to help create good object-oriented models. However the two rules comprise the essence of OO show examples in models that are created with, and without the application of these rules, is something we need to do a lot to help in developing better and more complex systems.

Future articles mentioned above:

• Active-Passive Pattern
• Time Inversion Pattern