Twitter follow Button



Hybrid Oriented Programming & Design

Embrace design, not dogma


We all seem to be coming around to this on our own rather quickly. I'll write it down here for my own clarity and as part of Creativyst's coding conventions, but it isn't all that complicated.


Objects are physical phenomena that occupy volumetric space. For the purpose of this discussion, objects have two important limiting attributes[1]:

  1. One object may not occupy two different places at the same time.
  2. Two objects may not occupy the same place at the same time.

Hierarchical classification (object oriented structure) works for representations of real-world objects because objects are objects. That is, they can only be in one place at a time and two cannot occupy the same place at the same time. We can therefore place an object within a hierarchical class representation of all the objects we know about and, if we put it in the right spot, we can be relatively sure we've reached the global (absolute) minimum - the most correct place for that object within the collection of all objects we know about.

As we add objects, we may not get it right on the first try, or even on the thousandth try, but eventually each object will wind its way down to its correct place in relation to all the other objects.

We can be relatively sure that there is exactly one right way to fit all the objects in correct relationship to each other. As new objects are discovered they will displace our existing objects and move them to various different places within the hierarchy. But the structure will always ensure we find the one and only one location where a given object and no other object should rest within the hierarchy of objects.

This is because the limitations of nodes in our object oriented hierarchical classification system perfectly match the limitations of real world objects. That is, they may only be in one place at any one time, and no two may occupy the same place at the same time.

For this reason, programs that simulate and represent our real world with all its objects are prime candidates for Object Oriented Design (e.g. desktops, shelves, cabinets, file-folders, and paper documents).

Concepts Are Not Objects

Some attributes of concepts:

  • Concepts may be members of multiple categories (categories are themselves concepts)
  • Concepts (including the concept of categories) may be classified into hierarchies of categories.
  • Concepts include a dimension of context and can occupy multiple contexts simultaneously.
  • Concepts don't exist in the physical universe (though we measure everything in the physical universe against them. e.g. "perfection").

OOP runs into difficulty when programmers attempt to apply it to concepts. For example, should I put accounting documents under documents in a sub-class of documents called accounting? Or should I add a sub-class called documents to the accounting class? Note how the problem of concepts not being objects pre-dates computers.

OOP attempts to resolve this dilemma with something called multiple inheritance. But when you apply multiple inheritance, you have lost the one disciplinary factor that makes object oriented design object oriented. You can no longer call your design object oriented if you have applied multiple inheritance. In fact, what you've got there is something that's been around since the dawn of programming.

OOP + Multiple-inheritance == spaghetti code

If you view a control-flow diagram of a source code module that is liberally constructed with OOP + Multiple-inheritance and one liberally constructed using say, GW-BASIC, there will be no discernible difference between the two modules. Both modules can be constructed to be spaghetti code and if the multiple inheritance feature is actually used, the OOP module is likely to be spaghetti code (s/liberally/poorly/).

What about friend classes?

Abstractions are Concepts

Because concepts are not objects, abstractions, being concepts themselves, are not objects. That said, even if you limit it to representing only things that are actual objects in the physical universe, OOP may still be the less desirable design choice.

There are times when, for performance' sake, even the behavior of well understood real-world objects are better off being abstracted rather than represented as true objects. As an example, molecules are real world objects with the limitations of real world objects discussed above. This makes them a fine candidate for true OOP design.

Still, if we are going to write software that models, say, the effects of neuro-transmitters and hormones on brain cells, and we wish to use true OOP, we will have to produce one instance object for each molecule of a given chemical in our simulation. We will also need to produce one instance of a molecule object for each and every molecule of the transport medium (e.g., the blood the hormones are dispersing through).

So, now our computer program will be processing trillions of molecule-objects in order to run one iteration of our algorithm. Could an acceptable approximation of our model be made by simply abstracting some known observations about how hormone molecules disperse in liquids?

If we decide to use the approximation, we may be tempted to force-fit such an abstraction to "look like" OOP. After all, we are ourselves objects, composed of objects, that have evolved entirely within other objects. But making it look like OOP will not make it OOP. A picture of a pipe is "not a pipe"[2]. Likewise, an abstraction of the behavior of a substance's molecules dispersing in liquid is not a representation of the molecules of that substance.

This should not be construed as an argument against OOP. In this example program, OOP will probably be the perfect design choice for neuron objects and many of their components, such as synapses and axons. But when it's time to write the behavior of chemical influences dispersing through blood or glial cells (intercellular tissue), it might be better to employ a programming method that uses a heuristic to mimic observed dispersion behaviors. At least for now, until RAM and processor power get REALLY cheap, we're probably better off resisting the temptation to simulate each molecule.

To bring this point home, there will also be many times when producing molecule objects for each molecule in a sample will be the correct choice for the solution being developed (pardon the pun).

The point: OOP is often the best choice. That is good design. OOP should not, however, be thought of as the ONLY, or even FIRST choice. That, frankly, is just following dogma.

Why Should It Matter?

Does it matter? I think so. If we are spending our creative and analytical energies trying to force-fit a concept-based problem to an object based representation, we are wasting those energies. We are also adding unnecessary confusion and complexity in a number of ways.
  • We will need to come up with an external strategy, such as a metaphor, allegory, or analogy, which will mate the concept-oriented problem to our object-oriented representation. This strategy represents an extra component/layer of work that is not an integral part of the solution. Though it could probably be fully defined in a comment, it still represents one more non-atomic "part" that could possibly get out of sync with its related parts.

  • We are requiring that the metaphor, allegory, or analogy we've used to fit the concept based problem to the object oriented representation be fully understood by those charged with maintaining and improving the solution. Even if they just think they do but don't, there will be an opportunity for defects and vulnerabilities to be introduced.

  • The problem of dealing with concepts in a universe composed of objects pre-dates computers. Users tacitly understand the problems associated with concepts not fitting into an object oriented world and compensate with a variety of strategies. One example of this is when a paper file can be correctly filed in multiple different places based on the context considered by the filer. In these cases, if the strategies used by the programmers do not match the strategies commonly used by the office workers, there is a chance for introduction of considerable differences between the data users enter, and the data expected by the software.

  • Even if you correctly mimic the strategies users have adopted to fit concept-based information into systems that are based on physical objects, your object oriented design technique may completely mask —and cause you to miss— advantages of implementing a true concept-based solution. In other words, the methods users have come up with over the years to fit their concept based knowledge into filing systems that are themselves objects may be clever, but limited because users traditionally had no other option. Computers give us a new, less limiting way to think about these strategies and may offer better solutions.


This article is © Copyright, Creativyst, Inc. 2005-2009 ALL RIGHTS RESERVED.

Links to this article are always welcome.

However, you may not copy, modify, or distribute this work or any part of it without first obtaining express written permission from Creativyst, Inc. Production and distribution of derivative products, such as displaying this content along with directly related content in a common browser view are expressly forbidden!

Those wishing to obtain permission to distribute copies of this article or derivatives in any form should contact me.

Permissions printed over any code, DTD, or schema files are supported as our permission statement for those constructs.


1. Some Caveats about Object Attributes:

  • Reality reference point:

    All discussion of "objects" here is in that universe which humans perceive and are composed of, meaning the collapsed, observed, macro-physical universe.

  • Temporal Illusion:

    An object can be made to appear to occupy two places at the same time by being moved between those two spaces faster than our human senses can discern. A film movie being a series of still pictures is a good example of this illusion.

  • Spatial Illusion:

    Two objects can be made to appear as occupying the same space at the same time by virtue of one object filling up spaces within the second object that are too small for human senses to perceive. An example here might be water and alcohol. [back]

2. Not a pipe - From the painting of a pipe by Rene Magritte titled Ceci n'est pas une pipe.
I've pushed his implication one rung up the representational ladder though. He starts with a thing (a pipe) and implies that the representation of that thing is not the same as the thing (not the pipe). I start with a representation of a thing (hormone molecules) and imply that an algorithm that aproximates some specific behavior of the thing (how it disperses in blood) is not the same as a representation of the thing. [back]

© Copyright 2005-2009, Creativyst, Inc.

Written by: Dominic John Repici