Drawbacks of object-orientation
Object-orientation generally involves creating classes or categories of variables, using inheritance on these classes, and polymorphic functions so that variables of one type can “pretend” to be other types. Object-oriented design has several benefits, of which you should be familiar by now, but there are also drawbacks to such an approach.
The Circle-Ellipse problem
Sometimes a widely-accepted definition of a category or class does not fit well in an object-oriented (OO) design. A good example of this mismatch with existing definitions and OO is the definition of a circle: a circle is an ellipse in which the major and minor axes are equal.
You might expect to create an ellipse class that has a major and minor axis, and a circle class that inherits from it:
However, in such a class model, the Circle class inherits all the properties and functions of the Ellipse class. This allows a user of the Circle class to change the minor or major axis, and make these axes out of sync. The circle has turned into an ellipse, but the variable is still a Circle object.
The Circle class may add a
radius variable and
function, but it cannot refuse inheriting the
set_minor_axis functions. So,
set_radius is superfluous, and does
not guarantee a circle cannot turn into an ellipse.
A different approach could be to make Circle and Ellipse completely separate:
But that seems like a significant failure of OO to model the real world.
For yet another alternative, the
functions can be virtual (not pure virtual):
The Circle class can reimplement these functions so that any call to
set_major_axis also sets the minor axis (to the same value), and
vice versa. The drawback of this approach is that the names
set_minor_axis do not truly apply to circles,
and how they work in the Circle class is somewhat counter-intuitive
(and must be documented somewhere).
The C++ FAQ has a good response to this problem, full of details and examples, and the following interesting quote (which begins the answer to question 21.8):
Question: But I have a Ph.D. in Mathematics, and I’m sure a Circle is a kind of an Ellipse! Does this mean Marshall Cline is stupid? Or that C++ is stupid? Or that OO is stupid?
Answer: Actually, it doesn’t mean any of these things. But I’ll tell you what it does mean — you may not like what I’m about to say: it means your intuitive notion of “kind of” is leading you to make bad inheritance decisions. Your tummy is lying to you about what good inheritance really means — stop believing those lies.
Look, I have received and answered dozens of passionate e-mail messages about this subject. I have taught it hundreds of times to thousands of software professionals all over the place. I know it goes against your intuition. But trust me; your intuition is wrong, where “wrong” means “will cause you to make bad inheritance decisions in OO design/programming.”
Really, that entire C++ FAQ page is a great read. Marshall Cline, the author, makes an admirable attempt trying to explain why our OO intuitions are some times completely inappropriate. That this issue is so complicated (he devotes 5,000 words to it) just shows how complex OO really can be.
The Expression Problem
The original definition of the expression problem is as follows:
The Expression Problem is a new name for an old problem. The goal is to define a datatype by cases, where one can add new cases to the datatype and new functions over the datatype, without recompiling existing code, and while retaining static type safety (e.g., no casts). — Philip Wadler
In terms of C++, the problem is essentially: can we define classes, and compile them, in such a way that in the future we can (1) create new subclasses (“add new cases to the datatype”) so that existing functions that use the original class will still work on our new class; and (2) create new functions in the existing classes (without changing the original code, which has already been compiled).
C++ lets us solve issue (1): create new subclasses that look like the original but act differently. This is possible if the original class had virtual functions. Our subclass can redefine what those virtual functions do. So far so good.
But C++ cannot solve issue (2): we cannot add functions to existing,
compiled classes. For example, we cannot add any function to the
string class, or the CDAccount class once they are compiled. (Even
though the CDAccount class is defined in the
cdaccount.h file and
you can add functions to that file, you will need to recompile, so
that the rest of the code knows how to use the new class
definition. When you update the class definition, stuff might get
rearranged, and old compiled code may no longer work.)
Philip Wadler continues,
Whether a language can solve the Expression Problem is a salient indicator of its capacity for expression.
I know of one language that does solve this problem, in case you are curious: Clojure.
As we know how, an inherited class can’t “refuse” to inherit data or methods from its parent class. Subclasses (deeper and deeper) just accumulate data and methods. Methods can be redefined but, unless polymorphism is enabled (in a superclass), the redefined methods won’t be activated when we use a pointer to the superclass.
Q: What’s big and gray, has a trunk, and lives in the trees?
A: An elephant — I lied about the trees.
What we’d like to be able to do is create, say, an
Animal class, a
Mammal class, and an
Elephant class (with the obvious inheritance
relations). Animals will have generic properites, like
Mammals will have methods like
grow_more_hair(). Elephants will have properties like
and methods like
Now, say we want to create a subclass of
Elephant, such as
GlassElephantFigurine that should share many of the same properties
Elephant class but not all (a figurine can’t roam or make
noise, for example), and should share some of the
but not all, etc.
You may object and believe that a glass figurine should not inherit
anything from the class representing real elephants. But then the
GlassElephantFigurine class has to duplicate much of the
data/methods in the
If you attempt to build the inheritance as described, you wind up having glass figurines that can roam, make noise, have hair, etc. which is ridiculous.
The problem is that a subclass cannot refuse properties/methods from its parent(s). It’s all or nothing.
Why this restriction? It can be proven that if we allow subclasses to
refuse properties or methods, then we completely lose the ability to
make accurate assumptions about subclasses. If subclasses can’t refuse
properties or methods, then we know for certain that any subclass or
Animal will have an
int age property, and any
subclass or sub-subclass of
Mammal will have a
method, and so on. If we can make these accurate assumptions, then we
can save ourselves the time of checking if they’re true. We know
they’re true. If subclasses can refuse properties or methods, we don’t
know they’re true, and can’t make any such assumptions; in fact, we
wouldn’t know anything about the subclasses by just looking at the
Read the article “I Lied About the Trees, Or, Defaults and Definitions in Knowledge Representation” by Ronald J. Brachman for an academic take on this issue.