several years of experience in OO software development. Why do intelligent and experienced professionals have difficulties with such an elementary
issue? We propose that the same mechanism used by
Kahneman to explain the bat-and-ball phenomenon
is also in operation here. Specifically, S1 with its quick
and effortless operation “hijacks” the thinking process
and produces a response that seems roughly appropri-
figure. The following discussion took place while
the participants were working in pairs on the task.
Ron: Let’s define login and register as objects.
Sharon: Do login and register seem like objects to
Ron: Why not?
Sharon: An object is a client, for example.
Under the demands of abstraction, formalization, and executability, the formal
OO paradigm has come to sometimes clash with the very institutions that produced it.
ate, while the slow and effortful S2 remains dormant.
This analysis gets additional support from the observation that the small cue offered by the instructor didn’t teach the participant anything new, only served to
wake up S2; the necessary knowledge was there all
along, but the dual system analysis is needed to
explain why it was not mobilized.
Why would S1 and S2 clash
about the meaning of
inheritance? In people’s
everyday intuition (S1),
inheritance is about transferring “stuff” (such as
property or money), and
the direction is usually
from the person who has more to the one who has
less. For example, in an informal poll we asked students, in the context of OOD, what is the relation
between a doctor and a paramedic in an ambulance?
A typical reaction was, “paramedic inherits from the
doctor because the doctor has more qualifications.”
Similarly, we predict that most people would say that
a student “inherits” from the professor (because the
professor has more knowledge) and not vice versa.
But in the OOD formalism (S2), the reverse is true:
the class with more functionally inherits from the one
Difficulties in identifying objects. One of the first
tasks in OOD is “carving a given scenario at its joints”
in terms of objects and classes. In one of the workshops the participants were asked to design an authorization system that will route users as follows:
• An existing user will login into the system.
• A new user will register and receive authorization.
Ron: Client is also an object. Login and register are
activated and operate within the system; therefore
they can be defined as objects.
Sharon: I’ve never seen an object login.
Ron: Don’t worry, it will be okay. You’ll see how I
design the system; it will be just fine.
Sharon [hesitates, at last reluctantly giving in]:
Okay, fine, although it doesn’t sound good.
Analysis: Ron’s decision is a typical S1 behavior, similar to that observed in the bat-and-ball task. In searching for objects he is influenced by the surface features
of the task (the salience of the terms login and register in the task description) rather than its essential
(though implicit) components. Unlike the bat-and-ball phenomenon, Ron requires more than a nudge to
change his mind, which seems to imply that his S2
knowledge in this regard is not too firm either.
Sharon, in contrast, seems to have a firmer sense of
the right objects, but this too is S1 knowledge, in the
sense that she cannot explain her choice. Her attempts
at convincing Ron involve expressions like “I’ve never
seen an object login,” and “it doesn’t sound good,”
which show that she relies on her vast past experience
(S1) rather than on analytical rule-based reasoning
(S2). Sharon’s example, in contrast to the other examples presented in this article, demonstrates how using
intuition may in fact contribute positively, even in situations of formal problem solving.
CONCRETIZING ABSTRACT CLASS
Confusing characteristics of abstract and concrete classes.
Abstract class is a class with at least one virtual function. Thus one can’t instantiate concrete objects
directly from an abstract class, but only through a
(concrete) inheriting class. In this example, Rebecca
chose to define an abstract class car and the following