Dale Skrien

Dept of Computer Science

Colby College

Waterville ME 04901

djskrien@colby.edu

Last year I had 3 weeks in which to teach the students in an upper-level class some introductory object-oriented design. The students had taken CS1 and CS2 using Java, but there had been almost no OOD in those courses. Therefore, they knew an object-oriented language, but I had to start the discussion of OOD from scratch. The 3-week period went fairly well; in particular, the students told me that they now understand much better some of the issues related to object-oriented design, even if they are not yet very good at doing such designs themselves. Based on this experience, here is my position describing how I would do it next time.

I realize that all the techniques I talk about here apply to all subjects we teach, not just OOD, but these techniques seem to be particularly important in this context.

To learn object-oriented design, class time must be spent on active learning in that the classes should be spent with the students working in groups, making class presentations, or defending or attacking proposed OOD's. Furthermore, there must be a strong motivational component to the learning. Therefore, I would ask the students in incremental steps to attempt a design before I talk about the relevant techniques so that, having struggled on their own and having a vested interest in their design, they can appreciate the new techniques in terms of how they enrich the conceptual framework or in terms of how they can simplify development.

On the first day of a 3-week period devoted to OOD, I present the students with a problem (last year I used the classic elevator controller problem). I tell them that they will have 3 weeks to solve the problem. I specify that their solutions must be Java programs that incorporate a GUI (either Java swing-based or Java awt-based) and that for the behind-the-scenes code, they are to use as object-oriented an approach as they can. I tell them to ignore the GUI for now. Without giving them any further design details, I break the class of approximately 20 students into groups of 2 or 3 and ask them to spend the rest of the period coming up with the objects they will use and the interactions among the objects.

The purpose of this first exercise was to see what they design on their own. In particular, some students think they already know all that is necessary regarding creating and using objects, and so it is important to let them design something and then have the whole class point out what is wrong with their designs. I wander around the class during this time mostly trying to ensure that the students are trying to solve the right problem. It always happens that some students are very interested in low-level implementation details already (even to the point of describing how a set can be implemented as a bitmap in an array of integers!). For homework, I ask the groups to write up their design, including the objects used, their properties, and their interactions. I ask them to create a simple scenario and describe what communication takes place among their objects in this scenario.

In the second class meeting, I have the students hand in their designs, and after a quick perusal, I choose two of them for class discussion. I ask the authors of the designs to walk through their scenario, with each author playing the role of one of the key objects in their design. Inevitably, the students will have glossed over or completely overlooked some factors, causing them to squirm a little. I introduce CRC cards at this point. The students' next homework assignment is to redo their design using CRC cards based on the class discussion.

In the third class, I again pick a couple of designs and ask the students in the class as a whole to compare these designs on several fronts, such as the scalability and generality of their design (e.g., in the elevator controller project, is their code usable for buildings with any number of elevators and any number of floors?), the reusability of their classes, and how tightly coupled various objects are. Inevitably, their classes are very tightly coupled and their design suffers from the students' attempts to put too much behavior in one class. To help them visualize the interactions that are going on, I introduce UML diagrams at this time. The next homework assignment is to redesign their classes again and draw UML class diagrams for their project.

In the fourth class, we again discuss their designs. I introduce Java constructs that they may find useful but that they may not have been exposed to in CS1 and CS2, such as inner classes. I ask them to think of places in their solution where such classes might be useful. Their homework for the next class is to write up their GUI design.

In the fifth class, we discuss these GUI designs (from an OOD perspective, not an HCI perspective). At this point, the students have had only a little exposure to the Java 1.1 event model (and that exposure often consists of programs in which an object is its own listener or in which one main object listened to all other objects using a large conditional branch statement) and so they are very fuzzy on what is really going on. Therefore I introduce the model/view/controller pattern, especially as it relates to the Java awt and swing packages. Then I have each group explain to the whole class how well their designs fit this pattern.

In successive meetings, we talk about other aspects of OOD, including other design patterns that might be useful in their solution, such as the Mediator pattern. In every case, I introduce the pattern as a solution to a previously-discussed flaw in their designs.

By this time, the students should have started coding some of their classes. I try to give them projects that do not involve a lot of coding if a good OO design is used, especially because there is not a lot of time left for coding after a couple of weeks of discussion. In particular, I help them with the Java GUI aspects that are less relevant to OOD at this level, such as the use of layout managers.