Rebecca: Let’s say car is an abstract class. Then, in
one design I can inherit from it Chevrolet and
Rolls-Royce, and in another design I will instantiate an object car with manufacturer value
Instructor: Is car an abstract class?
Rebecca: No, yes, that’s not the point...
In a subsequent interview with Rebecca, the
researcher probed the matter further.
Researcher: Rebecca, what did you mean by the car
Rebecca: I just tried to show that there are two
design possibilities using an abstract class, but I
got mixed up.
Researcher: What was the problem?
Rebecca: I wanted to show that you can instantiate
objects with parameters instead of using inheritance tree… but it didn’t work out.
Rebecca: Because the moment I instantiate objects, I
cannot define the class as abstract.
We note that this was not an isolated case. While it
seems that the participants in this study recognize
the distinction between abstract and concrete classes
in theory, several cases were observed where they
referred to abstract classes as if they had the characteristics of concrete classes. Even in some written
solutions, we found cases where an abstract class was
defined but was subsequently used as a concrete
Analysis: Rebecca knows the difference between
concrete and abstract classes, but this is S2 knowledge.
Our interpretation of how S1 worked in this example
follows from the dual nature of the relationship
between the natural and the formal conceptual framework concerning categories and objects. On the one
hand, OOD builds on the intuitions of the natural
concepts, but on the other hand, the natural system
sometimes clashes with the formal one. We propose
that this is what happened in Rebecca’s case. Specifically, in the natural categorization system [ 5], there is
no parallel for the formal OOD concept of abstract
class (a class from which no concrete objects can be
instantiated). Hence, when Rebecca’s S2 was not on
guard, her S1 took over and slipped from abstract to
concrete class. As before, a small nudge was enough to
wake up S2 and lead Rebecca to make the necessary
Identifying software development with coding.
Coding is an important software development activity, but
other no less important activities contribute to soft-
ware development, such as requirements analysis,
design, and testing. We observed participants underweighting these other activities, to the extent of identifying software development with coding. 2 The
following discussion occurred in an interview regarding time invested in different activities:
Ann: Most of the time I was occupied with development.
Researcher: What do you mean development?
Ann: You know, writing the code. For me coding
and developing are the same thing, even though I
know this is not correct.
Analysis: Ann’s first automatic response, that developing is the same as coding, is an S1 response. S1
consists of what is most accessible and what comes
most easily to mind; here the view of development as
coding comes to mind, presumably because the code
is the final and most tangible product of the whole
process, while the other components (such as design
and requirement analysis) are less conspicuous. The
interviewer’s question served as a nudge that woke
up S2, hence the utterance: “though I know it is not
correct.” In fact, her second pronouncement is a
good demonstration of an actual clash between the
two systems: S1 expressing the view that “coding and
developing are the same thing,” but simultaneously,
S2 objecting that “I know it is not correct.”
HOW INTUITIVE IS OO DESIGN?
So, how intuitive is OOD? Well, in a certain sense it
indeed is intuitive: our cognitive system certainly
makes extensive use of objects and categories, on
which this paradigm is built. However, as often happens in the evolution of formal systems, this relationship has a flip side [ 9]. Under the demands of
abstraction, formalization, and executability, the formal OO paradigm has come to sometimes clash with
the very intuitions that produced it. Thus, while
objects, classes, and inheritance certainly have an
intuitive flavor, their formal version in OOD is different in important ways from their intuitive origins.
Dual-process theory, imported from contemporary
cognitive psychology, highlights the underlying mechanism of those situations where our intuitions clash
with our more disciplined knowledge and reasoning.
Or, put in Kahneman’s words [ 4]: “Highly accessible
features will influence decisions, while features of low
accessibility will be largely ignored. Unfortunately,
there is no reason to believe that the most accessible
features are also the most relevant to a good decision.”
2This observation was obtained in a joint study with Peleg Yiftachel.