6
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ Are you trying to teach all of those patterns in one 10-20 minute lesson? $\endgroup$ – enderland Jan 5 '18 at 20:33
  • $\begingroup$ 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. $\endgroup$ – ctrl-alt-delor Jan 6 '18 at 11:04
  • 1
    $\begingroup$ 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 the-whiteboard.github.io/2016/09/02/patterns.html $\endgroup$ – Robert Harvey Feb 15 '18 at 0:04
  • $\begingroup$ 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. $\endgroup$ – Robert Harvey Feb 15 '18 at 0:22
2
$\begingroup$

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/

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.

$\endgroup$
  • $\begingroup$ 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." :) $\endgroup$ – Gypsy Spellweaver Jan 4 '18 at 17:59
  • 2
    $\begingroup$ 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. $\endgroup$ – pojo-guy Jan 5 '18 at 5:24
  • 1
    $\begingroup$ 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. $\endgroup$ – Buffy Jan 5 '18 at 11:15
  • $\begingroup$ @Buffy I wish I could give you a hundred upvotes for that last comment $\endgroup$ – pojo-guy Jan 5 '18 at 17:45
  • $\begingroup$ 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. $\endgroup$ – ctrl-alt-delor Jan 6 '18 at 11:10

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.