Explored. Designed. Deliveredsm
Concepts are not objects
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:
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:
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". 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.
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 Creativyst.
Permissions printed over any code, DTD, or schema files are supported as our permission statement for those constructs.
1. Some Caveats about Object Attributes:
2. Not a pipe -
From the painting of a pipe by Rene Magritte titled
Ceci n'est pas une pipe.