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 Chevrolet.

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

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.

Researcher: Why?

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 class.

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 distinction.

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. ² 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.”

²This observation was obtained in a joint study with Peleg Yiftachel.