Hybrid Oriented Programming & Design

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?

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.

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]