Design Patterns
We will investigate a handful of design patterns (in the context of OOAD) in this course.
Definition: A design pattern is a proven, reusable solution to a commonly occurring problem.
A bit of history: Gang of Four!
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (collectively known as the Gang of Four or GoF) wrote the book Design Patterns: Elements of Reusable Object-Oriented Software in 1994. These authors looked at over 300 projects that other software developers were working on (at the time):
- They recognized that many of the same problems kept appearing.
- They also noticed that solutions to the problems were roughly the same.
- Their book discusses these problems and solutions, identifying each as a pattern and giving it a name.
GoF categorized the patterns into three categories:
- Creational patterns - writing classes and creating objects.
- Structural patterns - aligning classes and objects.
- Behavioral patterns - interactions between objects.
We will look at samples of all three types.
Why should you learn about design patterns?
First and foremost to write good software: recognizing patterns can help you write code that is easy to maintain in the long-term; it helps you avoid writing hacky code. By "hacky code" I mean a software solution that accomplishes some goal by compromising on design principles that (good) programmers would much rather not compromise on.
The hardest part of applying patterns is being able to recognize them! That is, to identify the problem at hand as the underlying problem of a pattern.
Another reason is to be able to communicate with other software developers. It is typical during design sessions and code reviews, developers communicate by using pattern names without giving a full explanation as to what the problem and its solution are.