Design Patterns: Elements of Reusable Object-Oriented Software is a textbook written and published in 1994, but its content and methodology is fundamental to how to properly write object-oriented code.
However, the book itself is notoriously hard to read and follow along and is definitely not suitable for beginners who are just starting to learn how to code. I will try my best to summarize everything I learn from this book, hopefully to make it a bit less confusing and daunting when you look over your code 5 years in the future.
Elements of a good object-oriented software
Reusable elements
- Expert designers know not to solve every problem from first principles.
- First principles is defined as ‘fundamentals’, ground-up direct solutions for a problem. In this case, it refers to knowing how to use previous solutions to solve the problem, rather than solving it from the ground up again.
- Once they find a good solution, they’ll stick to it - refactoring it in other parts to better suit them, but maintains the same structure overall.
- These reusable elements may be something as small as a single function - or an entire design pattern.
Flexibility & maintainability
- Good objected-oriented design patterns should be specific enough to solve your problems while being general enough to be reapplied, maintained and modified without spending so much time refactoring.
- Polymorphism - good code should be adaptable, easily modifiable to fit new solutions
Easy communication
- Objects, designs and solutions don’t conflict with one another - making these design patterns more elegant and flexible.
Essentials of a design pattern
1. the pattern name
- The handle we use to describe the design problem. Naming them give developers the ability to communicate and discuss patterns.
2. the problem
- As each design pattern is suited for a different problem, the problem described is what tells you which design pattern to be using.
3. the solution
- These are the elements that actually make up the design and solve problems. As you want reusable code, the solutions are usually abstract; instead of building a solution for each specific case, a design pattern usually describes an abstract/general description of the elements required to solve a problem.
- Participants (classes and objects in a pattern), instances and their relationships and processes are all described here.
4. the consequences
- The results and, subsequently the trade-offs. Larger issues, how flexible the design is, how future-proof - these are dependent on the design pattern chosen.
Describing design patterns
Pattern name and classification
- Describes the essence of the pattern. Remember that these will be placed into your developer vocabulary.
Intent
- What does the design pattern do? What issue does it address?
Also known as
- Other well-known names for a design pattern
Motivation
- A scenario described that illustrates the design issue and how the pattern solves this issue.
Applicability
- What are the situations where this pattern may be used? What are examples of poor designs that can be corrected?
Structure
- A visualization of the design pattern.
Participants
- The classes and/or objects participating in the design pattern and their responsibilities.
Collaborations
- How participants interact with one another to carry out their responsibilities
Consequences
- Pros, cons? Flexibility?
Implementation
- Hints, pitfalls, techniques should you be aware of when implementing the pattern? Language specific issues?
Known uses
- Examples of the pattern found in real systems.
Related patterns
- What design patterns are closely related to this one?