<p>Design patterns covers a broad area. I'm going to assume that your students are beginners, more or less.</p>
<h2>Elementary Patterns</h2>
<p>A few people have developed some interesting elementary patterns for things as simple as loops and selection: <a href="http://www.cs.uni.edu/%7Ewallingf/patterns/elementary/" rel="nofollow noreferrer">http://www.cs.uni.edu/~wallingf/patterns/elementary/</a></p>
<p>These patterns help students program at the lowest level and, after introducing the patterns you can easily come up with small exercises that see whether the students actually use the patterns to guide their programming. Any exercise that requires a sequential if structure can have the students factor out the structure as a method and apply the &quot;Return, Not Else&quot; pattern, for example. There are many possibilities.</p>
<h2>Organizational Patterns</h2>
<p>In addition to coding patterns, organizational patterns can be used to both teach beginners good skills that will serve them well in the classroom and later in employment. For example, you can consider Extreme Programming (XP) or Scrum to be defined by simple pattern languages in which the practices are the individual patterns. Some of those practices may not be appropriate for beginners, but others are just good practice. For example, Pair Programming and Test First Development work well together and help students solve their programming problems. An in-class exercise in which you let students practice just those two skills under your guidance is, in my experience, very valuable. I've also presented larger projects to students as a deck of &quot;stories&quot;, the Product Backlog that gives beginners an overall decomposition into the parts of the solution they need to build. Often this is better than a narrative explanation of the problem when the still have no design skills.</p>
<h2>Classic Patterns.</h2>
<p>Many of the classic patterns are amenable for use in the beginner's curriculum. They will likely do these things anyway, but by formalizing the discussion of them introduces them to the value of patterns. For example Iterators are now ubiquitous in many languages. If you are doing GUI programming then the Observer Pattern is now standard. At a slightly higher level Model-View-Controller (MVC) can be discussed. This gives you a good way to discuss separation of concerns in programming. You can also organize your course so that you make it clear that, say, at the beginning the students build a Model without concern about how it is manipulated. It has a public interface of a few methods only. Then, once you have a model you can talk about the possibilities of (perhaps multiple) views and the associated controllers. But this is an organizational issue about the course. If they have to just build everything, they might wind up with a &quot;Big Ball of Mud&quot; (a pattern in fact, but not a good one).</p>
<p>Once the students are familiar with the <em>idea</em> of patterns you can introduce them to more complex ones with many parts. I find the Strategy and Null Object patterns to be useful in teaching polymorphism. With these patterns you can modify the behavior of an object dynamically, which leads you to program by composition (an object has interesting parts), rather than by inheritance. For example a situation in which an object must perform in one way the first time it is sent a message, but otherwise thereafter can use strategies, formalizing the behaviors, without using ad-hoc if-statements.</p>
<p>I realize I haven't given you many &quot;exercises&quot; here. My suggestion is that you can adapt many/most of the ones you are already familiar with to the use of patterns.</p>
<h2>Pedagogical Patterns</h2>
<p>You can also formalize your teaching methodology using patterns, so that your student interactions are guided by well-tested methods (patterns) that can make you a better teacher and make it obvious to you (and maybe to your students) <em>why</em> you do the things you do in the course.</p>

CC BY-SA 3.0
2018-01-04T17:59:30.157Z
Yea to _Pedagogical Patterns_. If you're going to teach patterns, it sure don't hurt to use them. Forces you to "_Put your money where your mouth is._" :)
Gypsy Spellweaver
CC BY-SA 3.0
2018-01-05T05:24:26.187Z
One thing to consider is that many (not all) patterns are established workarounds for weaknesses in the platform of choice. As such they may be language or environment specific.
pojo-guy
CC BY-SA 3.0
2018-01-05T11:15:30.183Z
It's a bit more subtle than that. The _solution_ in a pattern is driven by its _context_ and the prevailing _forces_. It is generally a mistake to try to apply a solution blindly. That is why patterns are written like they are. Most of the classic patterns arose in a C++ or Java sort of world. As such they may not be meaningful if you use Scheme, where different patterns would apply. Pattern writers spend a lot of time expounding on the forces, in particular, and those explain why the solution is correct _in the given context_. A pattern is much more than a problem-solution pair.
Buffy
CC BY-SA 3.0
2018-01-05T17:45:19.163Z
@Buffy I wish I could give you a hundred upvotes for that last comment
pojo-guy
CC BY-SA 3.0
2018-01-06T11:10:20.687Z
Yes GOF focused on the solutions, but the solutions are not the patterns. “You want the computer to do something many times, but if you tell the computer many times, then it takes a long time to type, and is difficult to change (as you have to make the change in many places). Therefore tell the computer once, and tell it how many times to do it. — use for-loop or repeat-x-times” That is a pattern.
ctrl-alt-delor
CC BY-SA 3.0
2018-01-04T17:29:07.767Z
2018-01-04T17:29:07.767Z
2020-06-18T08:36:57.023Z
Buffy
<p>When I teach a programming course, I like to spend 10-20 minutes in each lesson on some programming exercises that the students do in class. This lets me see whether the students understand the material, and also help them with technical problems they encounter. 
My next lesson is about design patterns, and I wonder what kind of programming exercises can I give?</p>

<p>EDIT: I am teaching classic design patterns, to 2nd year students who already know to program in Java. I will probably teach patterns such as Factory, Prototype, Adapter, Composite, Proxy, Observer, Template.</p>

CC BY-SA 3.0
2018-01-05T20:33:02.393Z
Are you trying to teach all of those patterns in one 10-20 minute lesson?
enderland
CC BY-SA 3.0
2018-01-06T11:04:31.317Z
Though the gang of four book was the book that introduced patterns to programmers it has little else going for it. It was inspired by Christopher Alexander book of about 250 patterns. Alexander said that this was just a few of the many patterns, G.O.F. said that their ≈20 was all that there is (even though they described MVC, but did not identify it as a pattern. Since this time many other patterns have been described in other books plop is one source of patterns.
ctrl-alt-delor
CC BY-SA 3.0
2018-02-15T00:04:06.193Z
**A word of warning:** we are currently graduating students who believe that Design Patterns are the elixir of software development, that they're the secret key to writing a program without having to think.  You don't build good software by stitching together a catalog of well-known software patterns; you build good software by writing code that solves problems. In the meantime, you learn software patterns, and their pros and cons, so that you can apply them where they are appropriate.  See also http://the-whiteboard.github.io/2016/09/02/patterns.html
Robert Harvey
CC BY-SA 3.0
2018-02-15T00:22:39.573Z
We are also graduating students who are obsessed with vocabulary (i.e. using "fancy words" without understanding the underlying concepts) and doing things the "right" way (as if there were such a thing), but that's a rant for another day.
Robert Harvey
<classroom-management><exercises>
What are good class exercises on design patterns?
# What are good class exercises on design patterns?

(Asked by: username_0 on 2018-01-04)

When I teach a programming course, I like to spend 10-20 minutes in each lesson on some programming exercises that the students do in class. This lets me see whether the students understand the material, and also help them with technical problems they encounter.
My next lesson is about design patterns, and I wonder what kind of programming exercises can I give?

EDIT: I am teaching classic design patterns, to 2nd year students who already know to program in Java. I will probably teach patterns such as Factory, Prototype, Adapter, Composite, Proxy, Observer, Template.

**Tags:** classroom-management, exercises

> **Comments:**
> **username_1**: Are you trying to teach all of those patterns in one 10-20 minute lesson?  
> **username_2**: Though the gang of four book was the book that introduced patterns to programmers it has little else going for it. It was inspired by Christopher Alexander book of about 250 patterns. Alexander said that this was just a few of the many patterns, G.O.F. said that their ≈20 was all that there is (even though they described MVC, but did not identify it as a pattern. Since this time many other patterns have been described in other books plop is one source of patterns.  
> **username_3**: **A word of warning:** we are currently graduating students who believe that Design Patterns are the elixir of software development, that they're the secret key to writing a program without having to think.  You don't build good software by stitching together a catalog of well-known software patterns; you build good software by writing code that solves problems. In the meantime, you learn software patterns, and their pros and cons, so that you can apply them where they are appropriate.  See also http://the-whiteboard.github.io/2016/09/02/patterns.html  
> **username_3**: We are also graduating students who are obsessed with vocabulary (i.e. using "fancy words" without understanding the underlying concepts) and doing things the "right" way (as if there were such a thing), but that's a rant for another day.  

---

## 1 answers

### Answer by username_4 on 2018-01-04. Score: 2

Design patterns covers a broad area. I'm going to assume that your students are beginners, more or less.

## Elementary Patterns

A few people have developed some interesting elementary patterns for things as simple as loops and selection: [http://www.cs.uni.edu/~wallingf/patterns/elementary/](http://www.cs.uni.edu/%7Ewallingf/patterns/elementary/)

These patterns help students program at the lowest level and, after introducing the patterns you can easily come up with small exercises that see whether the students actually use the patterns to guide their programming. Any exercise that requires a sequential if structure can have the students factor out the structure as a method and apply the "Return, Not Else" pattern, for example. There are many possibilities.

## Organizational Patterns

In addition to coding patterns, organizational patterns can be used to both teach beginners good skills that will serve them well in the classroom and later in employment. For example, you can consider Extreme Programming (XP) or Scrum to be defined by simple pattern languages in which the practices are the individual patterns. Some of those practices may not be appropriate for beginners, but others are just good practice. For example, Pair Programming and Test First Development work well together and help students solve their programming problems. An in-class exercise in which you let students practice just those two skills under your guidance is, in my experience, very valuable. I've also presented larger projects to students as a deck of "stories", the Product Backlog that gives beginners an overall decomposition into the parts of the solution they need to build. Often this is better than a narrative explanation of the problem when the still have no design skills.

## Classic Patterns.

Many of the classic patterns are amenable for use in the beginner's curriculum. They will likely do these things anyway, but by formalizing the discussion of them introduces them to the value of patterns. For example Iterators are now ubiquitous in many languages. If you are doing GUI programming then the Observer Pattern is now standard. At a slightly higher level Model-View-Controller (MVC) can be discussed. This gives you a good way to discuss separation of concerns in programming. You can also organize your course so that you make it clear that, say, at the beginning the students build a Model without concern about how it is manipulated. It has a public interface of a few methods only. Then, once you have a model you can talk about the possibilities of (perhaps multiple) views and the associated controllers. But this is an organizational issue about the course. If they have to just build everything, they might wind up with a "Big Ball of Mud" (a pattern in fact, but not a good one).

Once the students are familiar with the *idea* of patterns you can introduce them to more complex ones with many parts. I find the Strategy and Null Object patterns to be useful in teaching polymorphism. With these patterns you can modify the behavior of an object dynamically, which leads you to program by composition (an object has interesting parts), rather than by inheritance. For example a situation in which an object must perform in one way the first time it is sent a message, but otherwise thereafter can use strategies, formalizing the behaviors, without using ad-hoc if-statements.

I realize I haven't given you many "exercises" here. My suggestion is that you can adapt many/most of the ones you are already familiar with to the use of patterns.

## Pedagogical Patterns

You can also formalize your teaching methodology using patterns, so that your student interactions are guided by well-tested methods (patterns) that can make you a better teacher and make it obvious to you (and maybe to your students) *why* you do the things you do in the course.

> **Comments:**
> **username_5**: Yea to _Pedagogical Patterns_. If you're going to teach patterns, it sure don't hurt to use them. Forces you to "_Put your money where your mouth is._" :)  
> **username_6**: One thing to consider is that many (not all) patterns are established workarounds for weaknesses in the platform of choice. As such they may be language or environment specific.  
> **username_4**: It's a bit more subtle than that. The _solution_ in a pattern is driven by its _context_ and the prevailing _forces_. It is generally a mistake to try to apply a solution blindly. That is why patterns are written like they are. Most of the classic patterns arose in a C++ or Java sort of world. As such they may not be meaningful if you use Scheme, where different patterns would apply. Pattern writers spend a lot of time expounding on the forces, in particular, and those explain why the solution is correct _in the given context_. A pattern is much more than a problem-solution pair.  
> **username_6**: @username_4 I wish I could give you a hundred upvotes for that last comment  
> **username_2**: Yes GOF focused on the solutions, but the solutions are not the patterns. “You want the computer to do something many times, but if you tell the computer many times, then it takes a long time to type, and is difficult to change (as you have to make the change in many places). Therefore tell the computer once, and tell it how many times to do it. — use for-loop or repeat-x-times” That is a pattern.  

---

