Notes on Limitations of Pure OO Programming
David Livingstone
24th May 2011
Notes on Limitations of Pure OO Programming
Introduction
Conceptually, there are only 2 different „things‟ that arise in a program, data objects and
process objects.
A pure OO style of program design and implementation initially appears to have the
potential of being a simple and elegant way of integrating these 2 „things‟, since they are
both combined in object classes.
However in practice, this simplicity and elegance does not appear. Indeed a „pure‟ OO
language like Java appears to be conceptually worse than a „messy‟ OO language like
C++.
This note lists some OO limitations. It does not attempt to be a thorough review.
Program Design
1. Decomposition can only arise via object classes, whereas in practice it may well be
simpler to decompose by function or data as well. Functional decomposition is
particularly useful, and hence its omission is significant.
2. Decomposition within object classes down to several different levels of abstraction is
not well supported. Sub classes of classes, and the objects of sub classes and classes,
operate at the same level of abstraction. For example, let Programmer, Manager and
Secretary be IS_A sub classes of the Employee class; then Employee, Programmer,
Manager and Secretary objects all operate at the same level of abstraction.
Decomposition to a lower level of abstraction must be done within a class definition.
This is not always easy, and often not done because it would make class definitions
very large and cumbersome. Note that defining the data and procedural components
of a class is decomposition of objects into the components that represent them (their
encapsulation makes the object into a scalar), not decomposition to a lower level of
abstraction.
3. A class as a data type may be useful if the application expects to simultaneously
handle a significant number, and possibly a varying number, of objects all of that data
type. However if there is only ever one such object, then having a class is an overkill.
Indeed it is potentially misleading and confusing as it implies that there is more to the
class than actually exists in the system.
4. Sometimes it is unclear as to what a class should be about, because the class is
created because it is required by the programming language rather than by the logical
design. For example, if a tokeniser is a clear and distinct part of the software design,
it may not be implemented just by a procedure (which is all that is logically required)
but by a class which consists mainly of that procedure. Again the class is an overkill
and potentially misleading and confusing.
5. In [Br0095], Brooks reports the following comment from David Parnas : “Instead of
teaching people that O-O is a type of design, and giving them design principles,
people have taught that O-O is the use of a particular tool. We can write good or bad
Page 1 of 3
Notes on Limitations of Pure OO Programming
David Livingstone
24th May 2011
programs with any tool. Unless we teach people how to design, the languages matter
very little.”
6. The OO approach sometimes assumes that a system should be built like the
simulation of a physical system. Simula, a language originally designed for
developing discrete simulations (as opposed to continuous simulations), is often
quoted as the starting point for the OO approach. Thus the system consists of a
collection of objects that pass messages to each other. However some systems are
just not like that, e.g. finite-element packages and database management systems.
Therefore the OO approach should not be used for them. The question arises as to
how one can distinguish those situations where simulation does provide a suitable
model of the problem structure from those where it doesn‟t. Also in a large system, it
would be useful to distinguish those parts of it whose problem structure could be
represented by a simulation style structure and those parts that couldn‟t.
7. There is sometimes confusion between IS_A and HAS_A inheritance hierarchies.
For example, [Flan99] on page 806 describes an IS_A hierarchy as one where there
are fewer permissible objects of a descendant class than there are in its ancestor class,
the former being a subset of the latter, but in addition the descendant class has more
operator members or more data members than the ancestor class. While the former
fits an IS_A inheritance, the latter represents a HAS_A inheritance.
8. The justification for OO programming typically includes class inheritance as a means
of re-using software to increase programming productivity. However such re-use can
be difficult to achieve in practice. It typically only works where re-use occurs in
different parts of the same system, in the same project, or in a tightly defined
application area where programmers are not only very familiar with the area but also
with the library of classes available to support it. This is because in these cases the
inheritance hierarchy can be, and is, effectively managed. Where there is no effective
management, problems can arise during debugging that take more resource than is
saved by re-use; also if a new class is inserted into the middle of a hierarchy, the
hierarchy below the insertion can be corrupted, causing major problems.
Asymmetry
9. Message passing arbitrarily picks out one parameter of a procedure call. If
procedures were closed under the type, there might not be a problem, but in practice
they are usually not closed.
10. A „driver‟ is needed to set the whole system in motion and manage it. Therefore
there is always a „main‟ program. This is an exception to the general rule, and hence
confusing. (In Java, a program is initiated by reference to a class containing a „main‟
procedure within it).
11. Loops, IF/THEN/ELSE - CASE statements do not fit into OO. They are high level
functions/procedures that do not stem from any particular class, unlike normal
functions/procedures.
12. An object class intended to provide a data type defines both a set of permissible
values that objects of that type/class may take, and a set of permissible operators that
Page 2 of 3
Notes on Limitations of Pure OO Programming
David Livingstone
24th May 2011
may be applied to an object of that type/class. Unless there is closure under the
algebra for that type, which there typically isn‟t, some of the permissible operators
will also involve data of other types, as parameters and/or results. Thus a dependency
between types can arises; an object class can only be created after the other relevant
object class(es) has/have been created.
13. In Java, object classes designed as scalar data types do not always behave in a way
that is consistent with built-in scalar types, because of the pointers implicit in the
former but not in the latter.
Other
14. The OO approach to inheritance assumes that an object of a sub class may contain
more data members than an object of the parent class, but not fewer. While this may
be typically the case, when it is not true it can create problems. For example, a circle
class is logically a sub class of an ellipse class, but a circle has only one radius while
an ellipse has two. This can lead to confusion such as the footnote on page 101 of
[Flan99] suggesting that ellipses could „pragmatically‟ be a subclass of circles.
Bibliography
[Flan99]
[Flan99]
[Broo95]
David Flanagan. Java in a Nutshell : A Desktop Quick Reference.
[O‟Reilly, 1999].
N. Dale, C. Weems, and M Headington. Programming and Problem
Solving with C++ (2nd edition). [Jones and Bartlett, 2000].
F. P. Brooks Jr. The Mythical Man-Month : Essays on Software
Engineering, 20th Anniversary Edition. [Addison-Wesley, 1995, ch. 19 :
The Mythical Man-Month after 20 Years].
Page 3 of 3