Teaching Objects with Elementary Patterns

Joseph Bergin
Pace University
jbergin@pace.edu

For the last several years a group of educators has met several times at various meetings including SIGCSE, ChiliPLoP, and OOPSLA as the Elementary Patterns Working Group. All of us are interested in finding more effective ways to teach object-oriented concepts to novices, especially in the first computer science course. In addition to the core group, there are many other educators in the US and a few others interested in our work and who have put it to use in various ways.

Most of the members of the group would agree with most of what I have to say here, though they are personal observations.

The most important message, and perhaps the most controversial, is that teaching objects well requires new pedagogy. The teaching methodology used to teach procedural programming will not work, or at least, will not work well enough. For this reason, I've been developing pedagogical patterns to try to address this new way of teaching. A number of these patterns have been submitted to EuroPLoP 2000 and can be found at http://csis.pace.edu/~bergin/PedPat1.3.html. They form the beginning of a long work that attempts to build a pattern language for the design of courses introducing object-orientation from the beginning.

The next message is that educators must come to realize that object-orientation is not a simple addendum to procedural programming. It is more than a large scale structuring technique for procedural elements. Indeed, the thought processes of object programmers can be shown to be quite different than those of procedural programmers. This is the basis for saying that object-orientation is a paradigm shift from procedural methods. Too many educators seem to believe that object-orientation is just about classes, or just about classes and inheritance. If this were so, then object-orientation wouldn't have the benefits it does and would, indeed, be just a simple extension and could be effectively taught that way. This has been discussed at length in "Why Procedural is the Wrong First Paradigm is OOP is the Goal", at http://csis.pace.edu/~bergin/papers/Whynotproceduralfirst.html.

Instead, however, object-orientation is really about polymorphic run-time function dispatch, and this changes the game radically. The deep meaning of this is that the focus of control in programs changes from a client centered view appropriate in procedural programming to a server centered view in object programming. This requires a change in mental model for the programmer--a paradigm shift. The aim of the new pedagogy is to avoid the disruption that will necessarily occur if our students are made to suffer the negative consequences of moving through this shift. In industry, experience shows that to completely make the shift requires approximately eighteen months, during which the programs written are not well structured either procedurally or with objects. This is because the two paradigms fight each other in the programmer's mind. Two recent papers that illustrate the differences between procedural programming and object programming are:
Understanding Object-Oriented Programming at: http://csis.pace.edu/~bergin/ppoop.html.
Moving Toward Object-Oriented Programming and Patterns at: http://csis.pace.edu/~bergin/persongender.html.

Thirdly, we have found that patterns and pattern languages can be an effective supplement to this pedagogy. Some of the patterns we use are the simpler ones from the standard software pattern movements. We use Strategy, Null Object, Decorator, Singleton, Immutable, and Factory, among others. This helps show good object design in simple ways and also introduces the student to patterns so that they may later read the literature to gain more. We try to develop simple pattern languages around these otherwise discrete patterns as well, using, for example, Null Object, Singleton, and Strategy together to build lists. This example can be found in
Object Oriented Lists at: http://csis.pace.edu/~bergin/patterns/List.html.

The Elementary Patterns Working Group has undertaken a larger body of work as well. We have been writing patterns and pattern languages intended specifically for novices--Elementary Patterns. These patterns describe software solutions at a very low level. Indeed they describe things well known by every working programmer, but which are often mystifying to novices. Patterns and pattern languages have been developed for

These ideas have been informing our courses for a few years now. They have also been employed by others in developing courses and lab exercises. For example see Alyce Faulstich Brady's labs at: http://max.cs.kzoo.edu/~abrady/CS420W00/Labs/index.shtml. Look especially at the second and third week labs, which incorporate the Selection and Loop pattern languages.

The Elementary Patterns Home Page can be found at: http://www.cs.uni.edu/~wallingf/patterns/elementary/

The core members of the Elementary Patterns Working Group currently include myself, Eugene Wallingford, Robert Duvall, Owen Astrachan, Ed Epp, and Rick Mercer

 

April 15, 2000