The magic of ancestry and inheritance

So far, we've considered only two of the main aspects of object oriented design thinking: splitting a situation up into objects and keeping each object self contained. This allows systems to be created where independent objects pass messages to each other and each responds in characteristic ways to messages they receive. But, this is only half the story. The real power of object oriented design comes as a result of two other features that provide the organisation and the efficiency. The first of these is the phenomenon of ancestry and inheritance.

Newcomers to the concept of object oriented thinking and design are often bemused by a system that appears to have no organisation or controls. They cannot see how independent objects, passing messages to each other can be purposely organised, let alone have the ability to self-organise. The secret is in a characteristic of object oriented systems known in programming circles as inheritance or ancestry. This describes the ability of objects in a communication environment to be able to pass on a message to another object if it cannot understand or deal with it.

In object oriented programming systems (OOPS), all objects are designed with memories. In these memories are listed a number of specific messages that can be acted upon by code in another part of its memory. In this way any incoming message can be compared to this list of known messages and, if it is recognised, a particular piece of computer code goes into action when the message is received.

If an object receives a message that is not on its list, it will pass the message on to another object. The key here is to understand that the message is not passed to the next on the list of the sender of the message, it is passed on to an object that is known only to the receiver of the message. In other words the message sender sends out a message and doesn't have to be concerned about what happens if the message cannot be dealt with by the object it sends it to; that problem is left to the receiver of the message to solve. At a stroke, this saves the message sender from having to be concerned about any of the details involved in getting an appropriate response. This greatly reduces the amount of complexity that the message sender has to deal with: freeing up more time to spend on the demand side of a solution.

In simple systems of OOPS in computer programs, each object has, in its memory, only a single name and address of an object where unrecognised messages are sent. In computer terms this object is known as its ANCESTOR. The passing on of the message to an ancestor occurs within the private shell of the receiving object. This is invisible to any other object, so, the sender of the message is completely unaware that the message has been referred elsewhere. This can be thought of as being similar to a television quiz show: where if a contestant cannot answer a question they are allowed to phone a friend. If the person whom the contestant phones can give the correct answer it counts the same as if the contestant had given the right answer themselves.

The important point to note here is that the sender of a message is oblivious and unconcerned as to which object makes the response; all it knows is that a message is sent to an object and the response is made. It doesn't know or care that any other object is involved other than the one it sent the message to.

Object message passing doesn't stop at one message referral. If objectA sends a message to objectB and objectB also cannot recognise it, objectB will pass it on to its own ancestor, ancestorC. If objectC also cannot recognise the message, it might be passed on to objectC's ancestor, objectD. This message passing can go from one ancestor to another until one of the ancestor objects recognises and responds to the message.

This can be likened to the contestant in the quiz show phoning a friend for an answer to a question and the friend saying "I don't know, but, I'll ask my wife". His wife might not know the answer either, so, she may say, "Wait a moment and I'll ask the next door neighbour". The next door neighbour also might not know but will ask someone else. The referrals can continue from one person to another until at last somebody comes up with an answer to the question.

In this way, many objects can be tied together in a message path, so, it only requires one of the objects in the message path to be able to respond to the message for objectA to appear to respond and so get all the credit. This is why the object that an object passes unknown messages to is known as its ancestor: because the message passing object effectively inherits all of its ancestors capabilities, skills and knowledge. Not only of a single ancestor but all the ancestors of it ancestors.

Mapping this across to people in the technological world of the Internet. It is as if somebody is asked to produce a complex CGI script for a Web page. They may not even know what a CGI script is but if they can pass this request onto someday they know who can do it they can comply with the request. Even if they don't know somebody who can write the script they can ask somebody who might know someone else. If through a series of connections the script gets done and is passed back down the line of communication to the original person who was asked to produce the script, that person would have appeared to have responded to the request.

Similarly with information. If somebody is asked a question or set a problem to solve, they can refer it to an ancestor path and get the information they need or a solution to the problem. Clearly, anyone who has a string of ancestors consisting of all kinds of experts can appear to be a very useful and versatile person to know. Any technical question could be answered, or, any speciality function or service provided: as long as it is covered by the expertise of one of their ancestors.