3
$\begingroup$

I am teaching a course in object design patterns for the first time, and it is not a topic I am extremely well versed in. My students are well aware of this, and signed up for the course fully knowing that I would be exploring alongside them. They are pretty enthusiastic to learn together, particularly since software engineering is an extremely rare topic for high schools. They have all completed AP Computer Science A, meaning that they are familiar with object basics, polymorphism, etc.

I heard from a friend whose graduate degree is in SE that her professor had assigned student presentations about design patterns, and it seems like a good idea to me. I would like to assign groups to each learn about, and present, one pattern to the class. My current thought is to ask the students to structure their lessons thusly:

  • A description of the pattern itself (what is it?). Have students already seen it? (Such as factory pattern with iterators)
  • A working toy example of the pattern c#/unity (our platform for the course) to be share with their classmates
  • A uml diagram of the toy example
  • A uml diagram of the pattern in general (can be taken straight from the web)
  • Lead a discussion about when the pattern would be appropriate
  • Any other considerations that seem appropriate or important about the pattern
  • A small review quiz to be shared with the class (as learning reinforcement)

I will model what I expect with two object patterns myself first (I was thinking about presenting singleton and observer patterns, though I am open to other suggestions if there are better choices), then allow them time to work in their own patterns.

I figure that each group will have roughly 40 minutes to present, and 10 minutes out of a 50 minute period the next day for their reinforcement quiz.

Here are my questions:

Does this seem reasonable given the topic? Are there elements that I am missing that are specific to design patterns? Should I allow students to freely pick from the design patterns, or should I restrict them to easier ones? Is there anything else I should know before embarking on this path with my students?

Improve this question
$\endgroup$
3
  • 2
    $\begingroup$ Do students have a book on Design Patterns? I don't recommend the original GOF book as it was written before understanding about patterns had solidified (I know three of the authors and have worked with one of them). There is a later, more complete book that is equivalent in coverage but Java based and more mature (Patterns in Java: Grand). There are a lot of C# design pattern books but I don't recognize any of the authors and most are focused on dot net. $\endgroup$
    – Buffy
    Dec 13, 2021 at 15:33
  • 1
    $\begingroup$ @Buffy They have the free book Game Programming Patterns (gameprogrammingpatterns.com), which makes sense for our context. I've given them a printout of the introduction to the GoF book since I like the way that it orients the mind, but otherwise, we're not particularly using that (or any) book. The internet is our oyster. $\endgroup$
    – Ben I. ♦
    Dec 13, 2021 at 16:02
  • $\begingroup$ @Buffy: I fully agree. I always like to say that GoF is not a book about patterns, it as a book of patterns, a catalog. Teaching patterns with the GoF book is like teaching English by reading a dictionary. $\endgroup$
    – Jörg W Mittag
    Dec 17, 2021 at 20:25

3 Answers 3

Reset to default
2
$\begingroup$

I think the outline is fine, but it isn't clear from it that students will come away with the essential understanding of what patterns really are. They aren't just cool things to do, but an essential step in architecture. The fact that they were first invented by an architect, not a programmer, (Christopher Alexander) is important.

The materials you suggest don't seem to make this obvious.

The essential components of a pattern are

  • Name
  • Context (when it makes sense to use it)
  • Problem
  • Forces (what pushes you both toward and away from possible resolutions)
  • Solution
  • Examples of use

Of all of these, the hardest to grasp is the Forces. They aren't the reason why you use the chosen solution, but, rather, the things that need to be "balanced" for a true solution rather than an arbitrary one.

Since your students will probably be using different sources, I suggest that you require that they take each supposed pattern and put it into an outline form, separating out the essential components as above.

Discussions of the actual balance of competing/opposing forces can be very interesting.

I once had a fairly long long-distance conversation with another author about the Iterator pattern. His idea was that each data structure should come with a single pointer/reference variable that could single out a specific element in the structure. He wrote a book (or three) in which these were used to iterate through lists and trees and such.

But it took me a long time to convince him that he hadn't considered all the forces at play. In particular, an algorithm that required more than one such reference was hard to write. The proper balance separates the concept of the data structure from the iterator so that multiple iterators can be in play at the same time. (Yes, this was in the early days.) Now his books (quite good, generally) have got a better structure.

The "problem" with the GOF - Gang of Four book is that it doesn't discuss problems for the various patterns. But, again, I think they wrote the book a bit too early when the community discussing patterns (I wasn't there yet) had an incomplete idea of what a software pattern should be.

Focusing too much on the solution or the structure (UML, say) can leave you with unusable tools, since you need to be able to recognize the context in a given situation to be able to apply it and to know if the forces at play are actually the same (or close to) the forces that the given solution balances. If you don't see the context, you don't know which tool to reach for. If you get the forces wrong, you pick up the wrong tool for the task.

In particular, since it is complicated and since your students are young and somewhat inexperienced, one pattern per team seems right. Lots of discussion and feedback seems right. But you will need to guide it. But if they can put the pattern into "outline" form they will have a good basis and discussion can resolve around that, not around details of some implementation.

I would also suggest that you pick a set of patterns for your students that work together to build things. Some patterns are frequently used together and others are sort of esoteric. Pick the more common ones. The goal should be a mini "pattern language" that can form the core of their programming projects.

I suggest you get a copy of Alexander's A Pattern Language and try to grok the background of the origin story of software patterns. A lot of libraries probably have copies. You certainly don't need to read it all, but the point of it was "livable spaces". Something worth thinking about in software.

Improve this answer
$\endgroup$
4
  • 1
    $\begingroup$ I'm checking out Livable Spaces. It seems to be pdf'd on many professors' pages at universities. You are correct that "forces" is the most unclear part of your list - I'm hoping to make some sense of it with the book you mentioned. $\endgroup$
    – Ben I. ♦
    Dec 14, 2021 at 15:57
  • 1
    $\begingroup$ @BenI. The only way a search for Livable Spaces turned up anything useful was if I added Christopher Alexander to the search. He has a wikipedia page, also. $\endgroup$
    – Buffy
    Dec 14, 2021 at 17:22
  • $\begingroup$ Regarding your essential components, I would also add an essential property: patterns should be part of a pattern language, which also implies that patterns have relationships. That's one of the biggest flaws of the GoF book: it does have relationships (although it misses some, such as Iterator and Subject/Observer being category-theoretic duals of each other), but it is not a pattern language. $\endgroup$
    – Jörg W Mittag
    Dec 17, 2021 at 20:57
  • $\begingroup$ @JörgWMittag, no, it isn't a pattern language. As I said, the GoF book was written too early. We learned a lot after that, but a lot of that learning was actually generated by the existence of the book. Note that the "Principle of Relativity" is due to Galileo (IIRC), but it took until Einstein for a deeper understanding. $\endgroup$
    – Buffy
    Dec 17, 2021 at 21:07
1
$\begingroup$

I'm a student, not a professional educator.

I think the resource that helped me understand design patterns the best was Game Programming Patterns https://gameprogrammingpatterns.com/flyweight.html which includes many original Go4 patterns as well as some gamedev-specific ones. You mentioned in a comment that this is already the textbook for the course, which I think is fantastic.

I might try taking a look at it to get some inspiration for what students might include in their presentation. In particular, the book focuses on practical applications for each design pattern. It might be interesting for students to include in their presentation:

  • A non-UML diagram of the design pattern (basically "describe the pattern in your own words/images")
  • An existing app, program, or tool that they think uses their chosen design pattern, and what about the app that makes them think that design pattern is present.
  • A mapping of their implementation/classes to each part of the design pattern (I think having them present both the original pattern and their implementation would probably accomplish this)
  • An example scenario that would be very difficult/impossible to implement without their design pattern
  • Sample scenarios in which the design pattern would be totally inappropriate.
  • Their experiences working with the design pattern (did it make things easier, would it make things easier for a larger/smaller project)

I guess these suggestions generally highlight identifying design patterns in other contexts, instead of just reproducing them.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Hi Tavi, thank you for your thoughts! I like the distinction you've made about identifying versus reproducing, and I will modify my ask somewhat along these lines. Game Programming Patterns is already our textbook, so that's a good start already! $\endgroup$
    – Ben I. ♦
    Dec 27, 2021 at 23:36
  • $\begingroup$ I probably should have read the comment that mentioned your textbook oops. I'll try and reorganize/clean up my answer at some point. $\endgroup$
    – Tavi Kohn
    Dec 27, 2021 at 23:50
0
$\begingroup$

Beware the GOF book on design patterns: It has 3 problems.

Claims that there are only about 20 patterns

It states that it have all design patterns that there are. About 20.

The original pattern book had about 240, and stated that this is by no means all of them.

The GOF book mentions model view controller, and discusses how it can be implemented using design patterns. It does not list MVC as a pattern.

GUI confusion

All examples are for Graphical user interface design. This would continually confuse me. I would find a pattern that I thought was relevant. Start reading, and my brain would say “No this is not relevant”. My brain was matching to the GUI-ness of the pattern, and rejecting it. I could not train my self to overcome this. I have to re-write them (summarise them). The head-first book on the same patterns overcomes this.

Singleton

Singleton is an anti-pattern. It violates the single responsibility principle. It is both a factory, and whatever else you want it to be. Split out into a class for the main functionality and one of the factory patterns.

Conclusion

Other than that, it is a good book (but get the head first version). It was a pioneer in the programming field (but see also the Chritopher Alexander original). There are now many other books on programming patterns (e.g. Plop series)

Use singleton and mono-state (not in the book). Only to wrap badly written code: e.g. code that assumes that every PC has one or zero serial ports.

Improve this answer
$\endgroup$
9
  • $\begingroup$ I'm currently only using chapter 1 of that book, because that is the document where the authors laid out, philosophically, why this should be an area of study, and provided a lot of interesting general insights. No other book that I've seen has attempted the same. For the actual patterns, we're mostly hewing to "Game Programming Patterns", which is a much more modern take. $\endgroup$
    – Ben I. ♦
    Dec 17, 2021 at 19:28
  • $\begingroup$ I disagree about singleton. Preventing multiple instances is sometimes an essential requirement. And what "original" patterns book are your referring to? $\endgroup$
    – Buffy
    Dec 17, 2021 at 20:06
  • $\begingroup$ The lack of coverage in GoF is due entirely to the early stage of understanding at which it was written. New design patterns are published every year at PLoP and at EuroPLoP among others. $\endgroup$
    – Buffy
    Dec 17, 2021 at 21:09
  • $\begingroup$ @buffy arl.human.cornell.edu/linked%20docs/… $\endgroup$
    – ctrl-alt-delor
    Dec 17, 2021 at 21:14
  • $\begingroup$ I don't understand why you say the GoF patterns are primarily about GUI. I think the Observer pattern qualifies as it is a fundamental part of Model View Controller architecture. But I've use a lot of these "classic" patterns in building models with no UI components at all. I use Strategy and Decorator constantly (together). Iterator is used in many algorithms over data structures. $\endgroup$
    – Buffy
    Dec 17, 2021 at 21:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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