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 you?

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 with less.

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 discussion ensued.