Position paper for OOPSLA '96 workshop
"Teaching and Learning Object Design in the First Academic Year"

Teaching Object Patterns in the First Course

Eugene Wallingford
Department of Computer Science
University of Northern Iowa
wallingf@cs.uni.edu

Abstract

This paper advocates an approach to teaching introductory computer science courses based on the idea of object patterns. Such patterns give students an adequate vocabulary for analyzing problems, designing solutions, and implementing programs that is both abstract enough to make learning design possible and concrete enough to enable generation of effective, readable code.

1 Background

The desire to teach design in CS1 is, of course, not unique to the object-oriented (OO) classroom. When I first began teaching introductory computer science and computer programming courses, I quickly became interested in how to help my students think more abstractly about their designs and programs. Our courses involved primarily procedural languages at that time -- Pascal, Fortran, and so on. Over the course of the next couple of years, I increasingly organized my courses around a number of procedural patterns, prototypical fragments of code that addressed commonly encountered programming problems. These patterns gave students a vocabulary for discussing prob-lems and solutions at a higher level than programming language statements. In the fall of 1994, our department adopted an OO approach in CS1 and CS2.

Our goal was to teach OO thinking from day one, rather than incrementally introducing object-oriented ideas into courses that were still fundamentally procedural in nature. We intended to use CRC cards to help students analyze problems in an OO way, and we selected responsibility-driven design as our design methodology. In conjunction with these changes, I began to consider how I might apply the pattern

approach to our new first course. The issues facing me were much the same as those from before: How can I help my students think more abstractly about their designs and programs? What are the most appropriate abstractions to teach? What are the best vehicles for teaching them?

It is important to note that adopting an OO perspective in CS1 does not make these issues any easier to address. Indeed, an OO approach widens the gulf between abstraction and program, making the student's learning task even more formidable. Teaching just the right abstractions becomes even more critical. Students will likely focus their attention on language syntax, which distracts them from the already difficult task of learning how to design and program.

2 Position

This paper advocates an approach to teaching an OO-based CS1 course based on patterns [9]. Patterns have long been viewed as an important part of how we understand and shape the world around us. In the context of design, patterns are recurring solutions to the problems that confront designers. Each pattern encapsulates a well-defined problem and a standard solution. This solution consists of both a design and a description of how to implement it. By thus intertwining the problem, the solution, and the implementation, patterns allow the designer to refine them concurrently during system development. The use of patterns provides a new level of abstraction at which analysis, design, and implementation can be done.

2.1 Object Patterns

In the context of software development, patterns embody abstractions that are used to write and understand software. A pattern approach offers the novice programmer a new kind of tool. Rather than viewing programming language statements as the building blocks out of which to construct programs, students are taught to use patterns as the basic unit of analysis, design, and programming. The patterns provide a mapping from a type of problem to an effective algorithm and an effective implementation in code. In this way, small piecework that the students would otherwise have to continually redo is standardized into a larger unit that can be reused in various contexts.

A great deal of the pattern research originated and still resides in the object-oriented community [2,4]. However, the patterns produced by this work are not directly applicable to an introductory course. First, that work targets primarily more advanced software practitioners, identifying complex patterns that are not accessible to novices. Second, it tends to emphasize design issues, whereas a first course must also provide a significant amount of support for novice programming. The patterns that we introduce to novices must be more concrete and at a lower level of abstraction than those in the pattern literature.

StateMaintain a body of data and provide suitable access to it by other objects and human users.
ViewerDecouple an object's state from its presentation to other objects and human users.
ReaderDecouple an object's state from the objects and human users who provide information for its state.
CollectionMaintain a set of objects and provide a common interface to access them.
IteratorPerform a common action on some or all of the objects in a collection.

Figure 1: Object Patterns for Novices

I have identified a small set of object patterns for use in a CS1 course (Figure 1). These patterns are general enough to find application in the student's later experience, since they address basic issues of computation and decomposition. However, they also provide students with concrete support for coding objects that play particular roles. This is an important feature of any pattern set for use by novices, given their natural focus on the generation of working code in a new and unfamiliar language.

Pattern:Viewer
Problem:Need to display an object in a way that is not intrinsic to the object
Objects:model (maintains state data)

viewer (links to the model)

Code:
class model {
public:
/* constructors */
/* access functions */
/* other functions */
protected:
/* state data */
};
class viewer {
public:
// constructor
viewer(model*);
// display function
void view();
protected:
model* my_model;
};

Figure 2: The Viewer Pattern

Consider an abbreviated description of the viewer pattern (Figure 2). In CS1, viewers serve as an introduction to object associations. Three elements comprise each pattern write-up: a statement of the general problem, a description of the objects that solve the problem and their relationships, and a code skeleton that partially implements the description. As with any patterns, the programmer must furnish problem-specific code to fill in the commented parts of the pattern.

2.2 Course Organization

The course is organized around these prototypical patterns and a broad selection of different kinds of problems. These problems allow the student to gain experience recognizing the presence of a pattern, applying a pattern with minimal modifications, and applying patterns in contexts that call for more significant modification. With enough experience, students begin to see trade-offs in the selection and modification of patterns.

The process for learning an object pattern usually proceeds something like this. The student will examine several programs in order to recognize a patterns in existing code. They then analyze new problems that call for them to identify problem features matching the pattern and to implement simple solutions that follow the pattern closely. Finally, they are then introduced to problems that require increasingly greater degrees of modification to the pattern. In class, emphasis is placed on adapting the features of patterns to the details of specific types of problem.

As their "catalog" of object patterns grow, students also begin to solve problems that call for them to identify multiple patterns and to configure them into a more complex design. At this point, the utility of patterns becomes more salient to the students, who find themselves able to discuss a problem in terms of object roles and relationships, rather than in terms of statements in the target programming language. They are able to implement their solutions in stereotypical code and then modify their designs and programs in a principled, rather than random or haphazard, way.

2.3 Experience with the Approach

The object pattern approach has been evolving in my object-oriented CS1 course for the last three semesters. Though I have done no formal analysis of the effects of the approach on student performance and learning, I can offer several comments on my perception of its effects.

First, many students seem to benefit from the use of patterns. The effect is most pronounced in the large percentage of "average" students, who no longer face the daunting task of creating programs on an empty editor screen, one line at a time. By recognizing an appropriate pattern in a problem, they can immediately begin working with a "chunk" of meaningful code. However, the better students sometimes feel that the use of patterns limits their ability to create unique solutions of their own. Not all are immediately persuaded by claims that patterns channel their creativity toward the most interesting elements of a problem. Finally, the weakest students do not yet seem to benefit much from the approach, despite my increasing efforts to identify problems and solutions with which they can connect.

3 Related Work

The idea of using patterns to teach procedural programming did not originate in my work. Both Soloway's plans [8] and Linn and Clancey's templates [5] aim to capture similar "chunks" of programming knowledge. My pattern approach merely extended their work by making patterns the central focus of the course. It experimented with (a) a methodology for teaching an entire first course and (b) a complete set of patterns for this purpose.

Several educators have investigated "apprenticeship" approaches to instruction, in which students learn design and programming by first reading and modifying programs that have been written by experts [1,6].

The use of patterns is quite compatible with such a model. Patterns provide a high-level vocabulary for studying and understanding expert code. Later, they provide a skeletal structure from which to write new code.

But what about the use of patterns to teach object-oriented design and programming? One of the more exciting ideas currently being explored involves the use of "frameworks" [3,7]. A framework is an incomplete software system that provides support for specific kinds of programming (for example, GUI development) while leaving application components only partially completed. Again, the use of patterns is quite compatible with this kind of approach. The framework provides examples of good design and programming, and the object patterns provide specific tools for understanding the classes in the framework and the relationships among them. By using patterns, an instructor can teach the fundamental concepts of OO programming embodied in the framework through the content of specific problem-solving schema.

Integrating a pattern approach with a framework approach raises several interesting questions. How does one study a framework? Or extend it? Why is the code in the framework considered good? How can the selected object patterns be used to document the framework? One way to explore the relationship between frameworks and patterns would be to construct a framework specifically intended for use with a specific set of OO patterns, or to select a set of patterns to teach based on the relationships inherent in an existing framework. From my perspective, this is represents one of the most interesting frontiers in OO instruction.

4 References

  1. Astrachan, Owen, and David Reed (1995). AAA and CS1: An Applied Apprenticehip Approach to CS1, SIGCSE Bulletin 27(1):1-5.
  2. Coad, Peter (1992). "Object-Oriented Patterns," Communications of the ACM 35(9):152-159.
  3. Conner, D. Brookshire, David Niguidula, and Andries van Dam (1994). "Object-Oriented Programming: Getting Right at the Start," OOPSLA '94 Education Symposium.
  4. Gamma, Erich, Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns. Addison-Wesley.
  5. Linn, Marcia C., and Michael J. Clancy (1992). "The Case for Case Studies of Programming Problems," Communications of the ACM 35(3):121-132.
  6. Pattis, Richard E. (1993). "The 'Procedures Early' Approach in CS1: A Heresy," SIGCSE Bulletin 25(1):122-126.
  7. Pattis, Richard E. (1995). "Teaching OOP in C++ to Novices by using an Artificial-Life Framework." Working Paper.
  8. Soloway, Elliot (1986). "Learning to Program = Learning to Construct Mechanisms and Explanations," Communications of the ACM 29(9):850-858.
  9. Wallingford, Eugene (1996). "Toward a First Course Based on Object-Oriented Patterns," SIGCSE Bulletin 28(1):27-31. Available at http://www.cs.uni.edu/~wallingf/teaching/papers/sigcse96.html

5 Biography

Eugene Wallingford received his Ph.D. in computer science, specializing in artificial intelligence, from Michigan State University in 1992. He joined the faculty of the University of Northen Iowa that fall and was instrumental in introducing the object-oriented approach into the school's computer science curriculum. His first experience with object-oriented programming was as an AI graduate student, using LOOPS on a Xerox Dandelion. He has programmed extensively in Smalltalk and C++.