figure 2. example statement performed in the event handler.
OOP is at all appropriate for novices,
and no one suggests an objects-as-an-upper-level-elective approach or an
Perhaps the time has come to do so.
I judge each case on its own merits.
In general, I see nothing wrong with
declaring record types and subsystem
objects publicly, encapsulating only
the implementation of data structures
that are likely to change.
My second attempt at reusing OOP
software involved a software tool VN
that I developed for learning nondeterminism. It takes as input the XML
description of a nondeterministic finite automaton that is generated by an
interactive graphical tool for studying
automata. To facilitate using VN as a
single program, I decided to extract
the graphics editor from the other tool.
But OOP is about classes and Java enables the use of any public declaration
anywhere in a program just by giving
its fully expanded name. There were
just enough such references to induce
a cascade of dependencies when I tried
to extract the Java package containing
the graphics editor.
This is precisely the issue I raised
with the imaginary brake system. What
I wanted to reuse was the implementation of the graphics editor even if that
meant modifying the interface. I saw
that I would have had to study many
of the 400 or so classes in 40 packages,
just to extract one package. The effort
did not seem worthwhile, so I gave up
the idea of reusing the package and
i do not believe
there is a “most
that any method
included the (very large) jar file of the
other tool in my distribution.
I suspect I know what your next question is going to be: What paradigm
do you propose instead of OOP? Ever
heretical, I would like to question the
whole concept of programming paradigm. What paradigms are used to design bridges? My guess is the concept
of paradigm does not exist there. Engineering design is done by using technology to implement requirements.
The engineer starts from data (length
of the bridge, depth of the water, characteristics of the river bed) and constraints (budget, schedule), and she
has technology to use in her design:
architecture (cables, stays, trusses)
and materials (steel, concrete). I simply don’t see a set of alternative “
paradigms” for building bridges.
Similarly, the software engineer
is faced with requirements and constraints, and is required to meet them
with technology: computer architectures, communication links, operating systems, programming languages,
libraries, and so on. Systems are constructed in complex ways from these
technologies, and the concept of programming paradigm is of little use in
the real world.
It is easy (and not incorrect) to dismiss
what I have written as personal opinion
and anecdotes, just as I have dismissed
OOP as based upon personal opinion
and anecdotes without solid evidence
to support its claims. But the difference
between me and the proponents of OOP
is that I am not making any hegemonic
claims for my opinions. I do not believe
there is a “most successful” way of structuring software nor that any method is
“dominant.” This hegemony is particularly apparent in CS education, as evidenced by the objects-first vs. objects-later debate concerning teaching OOP
to novices. No one questions whether
I will conclude with a “to-do list”:
˲ ˲ Proponents of OOP should publish analyses of successes and failures
of OOP, and use these to clearly and
explicitly characterize the domains in
which OOP can be recommended.
˲ ˲ Software engineers should always
use their judgment when choosing
tools and techniques and not be carried away by unsubstantiated claims.
Even if you are constrained to use a
language or tool that supports OOP,
that in itself is not a reason to use OOP
as a design method if you judge it is as
˲ ˲ Educators should ensure students
are given a broad exposure to programming languages and techniques. I
would especially like to see the education of novices become more diverse.
No harm will come to them if they see
objects very, very, late.
1. Astrachan, o., bruce, K., Koffman, e., Kölling, M.,
and reges, S. resolved: objects early has failed.
SIGCSE Bulletin 37, 1 (feb. 2005), 451–452. doI:
2. ben-Ari, M. distributed algorithms in java. SIGCSE
Bulletin 29, 3 (Sept. 1997), 62–64. doI: http://doi.
3. gabriel, r. Objects Have Failed: Notes for a Debate,
4. gries, d. A principled approach to teaching oop
first. SIGCSE Bulletin 40, 1 (feb. 2008), 31–35.
5. grimm, K. Software technology in an automotive
company: Major challenges. In Proceedings of
the 25th international Conference on Software
Engineering (portland, or, May 3–10, 2003).
International conference on Software engineering.
Ieee computer Society, washington, d.c., 498–503.
6. hadar, I. and leron, u. how intuitive is
object-oriented design? Commun. ACM 51,
5 (May 2008), 41–46. doI: http://doi.acm.
7. hartenstein, r. the digital divide of computing. In
Proceedings of the 1st Conference on Computing
Frontiers (Ischia, Italy, Apr. 14–16, 2004). cf 2004.
AcM, new york, 357–362. doI: http://doi.acm.
8. jacobs, b. Object Oriented Programming Oversold!;
9. wegner, p. dimensions of object-based language
design. In Conference Proceedings on Object-Oriented Programming Systems, Languages and
Applications (orlando, fl, oct. 4–8, 1987). n.
Meyrowitz, ed. oopSlA 1987. AcM, new york, 168–
182. doI: http://doi.acm.org/10.1145/38765.38823.
Mordechai (Moti) Ben-Ari ( firstname.lastname@example.org) is an
associate professor in the department of Science teaching
at weizmann Institute of Science in rehovot, Israel, and
an AcM distinguished educator.