Intent:

Motivation:

Most readers of a book on design patterns already know that they want to learn a pattern. The reason they picked up that pattern was because they have read the summary and think it is relevant to their problem.

With a typical introductory classroom situation, however, students may not yet have this motivation. If we start by giving them a pattern name and then talking about the pattern, we could lose half the class before engaging their interest.

Applicability:

Structure:

Abstraction:
After you take the students through the example, then you can point out the aspects which can be applied in other instances. You can point out general principles, and then finally end up with describing the general pattern itself.

Consequences:

After a few patterns introduced in this way, the students will start appreciating the power of patterns and become eager to learn the next pattern. At this point, you can then return to introducing them by name, motivation, and context.

Implementation:

Concrete Example:
"One day, Maria's sink backs up. But she lives in a small town with only one plumber, a Vietnamese refugee named Tuan. Maria doesn't speak Vietnamese and Tuan's English is very poor. Fortunately, Maria has a friend, Jim, whose family came to the USA with the fall of Saigon, and thus he knows both English and Vietnamese very well. So Jim translates for Maria and Tuan gets the job done, and everyone is happy.

"An analogous situation often happens in software. For example, Fred gives you a program that reads data from files using a File object. Mary gives you a HTTP client object that takes data from web pages.

"Now you want to modify Fred's program so that it can take data from web pages, but the protocols for the File object and the HTTP client object do not match. So you write a new object that sits in front of Mary's HTTP client object and presents a File object's interface for Fred's program.

"In this way, Fred's program can now read data from the web using Mary's HTTP client object.

"This kind of situation often comes up in OO when you have objects from different sources, which expect different protocols. It happens often enough that we've got a name for it: the Adaptor Pattern.

Abstraction:
"The Adapter Pattern tells you how to convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces. Here is a diagram of how it works...

Related Patterns:

Example Instances:

• Smalltalk programming course
• Design Patterns
• Mathematical abstractions

References:

[GoF]
"Design Patterns" by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides; Addison-Wesley 1995.
http://st-www.cs.uiuc.edu/users/patterns/DPBook/DPBook.html

The following two patterns are from Dana Anthony's paper "Patterns for Classroom Education". I am including them here because I refer to them in my pattern.

Acquaintance Examples

Problem:

Constraints and forces:

If a student is completely unfamiliar with an example's basis, the instructor can spend more time explaining the example than using it. If the instructor is trying to demonstrate the creation of abstract classes, and uses as the example "Control Chart", which has as concrete subclasses "Non P Control Chart" and "X Bar Chart" among others, he doesn't want to spend more time explaining what X Bar means than what the difference between abstract and concrete is.

On the other hand, if the student is an expert in the example domain, the student can become bogged down in the example's domain details, and fail to see the point the example was intended to illustrate. If the instructor is trying to explain when to use a Phone Number object instead of an array of strings representing the area code, exchange, and station of a phone number, she doesn't want the telephony expert student arguing whether exchanges are a valid description of how phone numbers work these days.

Solution:

If a class is homogeneous, with all students having expertise in the same domain, an Acquaintance Example can serve as an "ice-breaker", to get students to see how to apply their new knowledge. Then the instructor can supplement the Acquaintance Example with an example closer to the students' domain, to demonstrate that their new knowledge applies to their domain of expertise as well.

Colorful Analogy

Problem:

Constraints and forces:

Solution:

The example I see most frequently using the colorful analogy is the explanation of the difference between identity and equality in objects. The analogy is a story of a restaurant patron who sees another diner eating a delicious-looking lasagna. He tells the waiter, "I want what she's having." Equality would mean the waiter goes into the kitchen and gets another plate of lasagna for him. Identity would mean that the waiter takes the lasagna the other customer is eating, and gives it to him. With the right analogy, a single word (in this case, "lasagna") can become a touchstone that recalls enough of the details of the explanation to make sense.