Do We Really Teach Abstraction? Paolo Bucci, Timothy J. Long, and Bruce W. Weide Computer and Information Science The Ohio State University Columbus, OH 43210 {bucci,long,weide}@cis.ohio-state.edu Abstract According to Norman, when done properly, abstraction Abstraction is one of the cornerstones of software develop- introduces the possibility for completely new ways of think- ment and is recognized as a fundamental and essential prin- ing about the system being abstracted. The new representa- ciple to be taught as early as CS1/CS2. Abstraction tion enhances our ability to think about the external supposedly can enhance students’ ability to reason and behavior of the original system through the use of terms that think. Yet we often hear complaints about the inability of are fundamentally different from those in which its internal CS undergraduates to do that. Do we supply students with details would be explained. It is critical to note that the ben- the tools they need to reach their potential to think carefully eficiaries of both information hiding and abstraction are and to reason rigorously about software behavior? Typically human beings; computers do not care at all about either. we do not, but as educators there are techniques we can use It is the central claim of this paper that, despite broad agree- to help our students develop such skills starting in CS1/CS2. ment about their fundamental importance, both information hiding and abstraction are severely shortchanged by current 1 Introduction CS1/CS2 pedagogy. More specifically, we claim that stan- Abstraction and information hiding have long been recog- dard pedagogical practices tend to compromise the human nized as fundamental and essential principles in software dimension of information hiding and fall well short of help- development, and are usually given positions of prominence ing student learners to realize an increased ability to reason in computer science curricula as early as CS1/CS2 [1, 2, 5]. and think carefully and rigorously as a benefit of using Information hiding and abstraction can be thought of as abstraction. complementary aspects of one general idea: hide the details Our claim is perhaps surprising and certainly requires justi- of a complex system while providing a simpler “cover fication. After all, when we teach objects using, for exam- story” to explain those aspects of the system that are of ple, abstract classes in C++ or interfaces in Java together interest. In this context then, we view abstraction as present- with concrete classes, are we not teaching information hid- ing a cover story for hidden detail. ing and abstraction? Clearly these programming-language Why are these ideas so important? As Don Norman [4] mechanisms provide information hiding in a technical sense points out: “A good representation captures the essential — access to concrete-class internals is restricted by the elements of the event, deliberately leaving out the rest. ... compiler. But what about the human dimension of informa- The critical trick is to get the abstractions right, to represent tion hiding? If our presentations to students of concrete the important aspects and not the unimportant. This allows classes immediately follow our presentations of abstract everyone to concentrate upon the essentials without distrac- classes, inevitably information hiding will be compromised tion from irrelevancies. Herein lie both the power and the in the minds of the students, though not technically compro- weakness of representations: Get the relevant aspects right, mised in programs. Further, the programming-language and the representation provides substantive power to mechanisms we teach do very little to encourage the cre- enhance people’s ability to reason and think; get them ation of appropriate cover stories, other than to require oper- wrong, and the representation is misleading, causing people ation prototypes. Operation prototypes alone do little to to ignore critical aspects of the event or perhaps form mis- increase students’ ability to reason and think about the guided conclusions.” behavior of operations being prototyped, even when com- bined with specification-by-wishful-naming. Of course, by standard practice we often include natural-language descriptions of the operations in addition to the prototypes. However, it is our contention that such descriptions still do not help students reach their potential to reason and think carefully and rigorously about the behavior of operations. In the remainder of this paper, we present two examples in Insert is invoked to insert the integer i into the list loi. If stu- support of our contentions. The first example is a traditional dents were asked to fill in the values of the objects in box 1 container class that is typically presented in CS2. The sec- after the declaration of loi and before the invocation of the ond example is a simple class that might be presented quite Insert operation, and in box 2 after the call, what values early in CS1. would we expect our students to record? 2 Traditional Presentation of Lists It should not be surprising if some students drew pictures of a singly linked list representation of loi in both boxes. Why? For our first example, we consider a typical cover story for a Immediate presentation of one or more implementations of list abstraction. Usually the data type is described first; that lists has compromised information hiding in students’ is, we start with a description of the values that list objects minds and thus any abstraction has been lost [3]. Other stu- might assume. For example, we might say “a list is a linear dents might attempt to record values for loi based on the sequence of items with a current position indicator”. This is description “linear sequence of items with a current position followed by the operation prototypes and descriptions of indicator”. Even in this case, it is not clear exactly what stu- their behavior. Let’s assume there are operations to insert dents might write down. Why? Unless notation has been and remove items from a list and to change the position established for recording values of “linear sequences with a indicator. Then the description of an insert operation might current position indicator”, we should not be surprised to be “Insert (l, x) inserts item x in list l at the current posi- see a considerable variety in how students record values in tion”. (At times, requires and ensures clauses might be used the two boxes, even among students who are attempting to to describe the effect of the Insert operation. Even so, the think in terms of the cover story. degree of formality is essentially what we have just stated.) Other operations would be described similarly. At this point, it is tempting to dismiss concerns about how students might fill in the tracing table. Are uniformity and The cover story above might be followed by an example use rigor in such tasks really that important? After all, students for lists. Whether an example is present or not, it is custom- somehow “get” lists, even if each in their own way. How- ary for CS2 books to present one or more implementations ever, suppose we asked students to trace through a much of lists in close textual proximity to the cover story. A fre- more substantial example. Would their informal intuitions quently used implementation involves a singly linked list of and individualized notations serve them sufficiently well to nodes and pointers. Here is a possible representation of a achieve clear individual understanding? Would differences list containing the integers 3, 1, 2, and 4, in that order, and between individuals facilitate or impede clear communica- with current position indicator on 2: tion between them? Does this presentation of lists employ abstraction in such a way as to provide “substantive power to enhance people’s ability to reason and think”? We are data 3 1 2 4 convinced it does not. next null 3 Improved Presentation of Lists In order to realize the full potential of abstraction as start described by Norman, we need more explicit models of type cur_pos values and of operation descriptions. One way to accom- plish this is to use the time-tested and time-proven idea of To begin to understand the pedagogical shortcomings of this mathematical modeling. Specifically, we can use mathemat- presentation of lists, suppose that immediately following the ical types to describe (i.e., to model) program types. This presentation, we asked students to complete the following powerful idea allows for exact descriptions of the values of tracing table. complex objects (beyond built-in types) and of the behavior of operations on those objects. In CS1/CS2, almost all of the Statement Object Values models we need to use in this approach are familiar to stu- object loi: List_Of_Integer dents, such as sets, functions, tuples, integers, etc. object i: Integer i = 5 We should be careful to introduce students to specific nota- tion to be used with these models. The models then provide loi = ??? i = 5 1 an excellent mechanism for creating cover stories. In a pre- Insert (loi, i) cise notation, all relevant information can be described loi = ??? while leaving out unimportant details. As Norman points i = ??? 2 out, extraneous detail can create confusion and can cause errors and misguided conclusions. In the table, a list of integers, loi, and an integer, i, are Here is the abstract description of a List component in a dia- declared, the value of i is set to 5, and the list operation lect of the RESOLVE language [6, 7]. The abstraction employs mathematical modeling. Note that this is a generic ments from mathematical string theory. For example, the component (i.e., a template) parameterized by the type of post-condition of Insert is s.left = #s.left and s.right = the items that can be inserted in a list (type Item).