Design Patterns
Spring 2022
Introduction
This week's paper is really an extension of last week's paper and discussion. We have followed the development of software engineering and programming languages up to the advent of object-oriented languages and design methodologies, and last week you read Booch's attempt to explain OO to a non-OO world. Part of his argument was that it was better for supporting programming-in-the-large because of its ability to package up related code and data and abstract it away from the rest of a large software system. In the handful of years that followed, as the software development community got more experience designing programs in terms of interacting objects, it was recognized that some general organizational "themes" appeared more than once in these systems. These meta-level design "templates" could be studied and shared as a means of simplifying future projects.
In the first line of the paper below, the authors say "We propose design patterns as a new mechanism for expressing object-oriented design experience". The approach they outline for designing software and communicating best practices became hugely influential — so much so that the group of authors has since become known as the "Gang of Four", or simply GoF. Every respectable software engineer today has a copy of their "Design Patterns" book on his or her shelf. There's been some backlash too though, as the useful limits of the approach have been explored. Read the first paper below until at least p.10, skim the list of patterns on p.13, then read at least the "Abstract Factory" pattern description (the first pattern) so you get a sense of how they're structured and what they're trying to capture and convey. The second paper below is optional. It's written by one of the GoF a couple of years later, and suggests that they've found patterns useful in lots of development projects.
Questions
Here are some questions you might try to answer as you read:
-
What's the point of Design Patterns?
-
What's the relationship between design patterns and classes/objects?
-
What's the relationship between design patterns and programming languages?
-
The "Jurisdiction" categories in Table 1 seem quite dissimilar. Do all of the entries in the table deserve to be equally considered "design patterns"?
-
Which of the points in the "Summary of Observations" seems the most valid or important? Do they mesh with your experiences?
-
What would Backus say about design patterns? (Skim "Can Programming be Liberated" again for insight.)
-
What would Dijkstra say about design patterns? (Skim "Humble Programmer" again for insight.)
-
What would Booch say about design patterns?
-
Dig up some comments about design patterns on the web, positive or negative, and share them in discussion.
Papers
-
Erich Gamma, Richard Helm, Ralph E. Johnson, and John M. Vlissides. 1993. "Design Patterns: Abstraction and Reuse of Object-Oriented Design." In Proceedings of the 7th European Conference on Object-Oriented Programming (ECOOP '93), Oscar Nierstrasz (Ed.). Springer-Verlag, London, UK, UK, 406-431.(link)
-
[OPTIONAL] Richard Helm. 1995. "Patterns in practice." In Proceedings of the tenth annual conference on Object-oriented programming systems, languages, and applications (OOPSLA '95). ACM, New York, NY, USA, 337-341. DOI: https://doi.org/10.1145/217838.217873