The Design Patterns Companion

Scott L Bain

• Publisher: Project Management Institute
• Year: 2020
• Print ISBN:
  9781628256581
• eBook ISBN:
  9781628256598
• Topic: Business
• Subtopic: Project Management
• Index: Business

Design patterns are not "reusable solutions" but instead create a rich language developers can use to communicate, collaborate, and make collective decisions about design. When you study design patterns, you are teaching yourself about what a good design is and why. Design patterns exemplify the principles and strong practices that developers can depend on to build high-quality solutions. Developers can rely on these essential skills to guide their design considerations. Scott L. Bain has trained thousands of developers in design patterns for over 20 years, providing them with a rich background in this valuable discipline.

Table of Contents

Introduction From the Author

What Design Patterns Represent

Design to Interfaces

Favor Composition Over Inheritance

Encapsulate the Concept That Varies

Qualities, Principles, Practices

Qualities Patterns Share: Strong Cohesion

Qualities Patterns Share: Proper Coupling

Qualities Patterns Share: Avoiding Redundancy

Qualities Patterns Share: Robust Encapsulation

Qualities Patterns Share: Testability

Principles Patterns Follow: Open-Closed

Principles Patterns Follow: Liskov Substitution

Principles Patterns Follow: Dependency Inversion

Principles Patterns Follow: Separation of Concerns

The Patterns Themselves

The Abstract Factory

The Adapter

The Bridge

The Builder

The Chain of Responsibility

The Composite

The Decorator

The Facade

The Flyweight

The Mediator

The Memento

The Mock Object

The Null Object

The Object Pool

The Observer

The Proxy

The Singleton

The Strategy

The State

The Template Method

The Visitor

Practice: Programming by Intention

Practice: Encapsulate Constructors in Simple Classes

Practice: Encapsulate by Policy, Reveal by Need

Practice: Adhere to a Coding Standard

Acknowledgments

References

Introduction From the Author

Design patterns were originally delineated in the seminal work of the “Gang of Four”: Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. They, in turn, were responding to an earlier work by the architect Christopher Alexander, The Timeless Way of Building. The Gang of Four's work, Design Patterns: Elements of Reusable Object-Oriented Software, received a lot of attention when it was originally published in 1994.

Some have suggested, however, that the industry has moved beyond the patterns in the more than two decades that have passed since its publication, and that in the age of agile processes and test-driven development, the patterns are no longer relevant. They say that patterns represent an old view, namely “big design up front.”

I disagree. Not only do I think the patterns are relevant today, I believe they are far more relevant than they were when the work was originally published. Here's why:

Patterns form a rich language of design. This is all the more important now that nearly all software projects are highly collaborative. We need reliable ways to communicate and make group decisions. Nearly all complex human activity involves specialized language: medicine, law, engineering, etc. They all have their own rich nomenclature to describe what is being proposed, or what has been done.

Patterns all follow the principles of good design in different ways. This means they are highly changeable without decay. The agile movement says, among other things, that we must embrace change. The patterns help us to do this.

This book is not meant to teach you the patterns; see the References section for books that do. This is meant to be a field guide for those who are already pattern practitioners, something to refer to as part of your day-to-day activities.

What Design Patterns Represent

The Design Patterns movement, begun (in software) by the Gang of Four (GoF) (Gamma, Helm, Johnson, & Vlissides, 1994), essentially elevated certain design elements as valuable, repeated, and high-quality examples of a particular approach to design.

Their general advice was given in three parts:

1. Design to interfaces.
2. Favor composition over inheritance.
3. Encapsulate the concept that varies.

All patterns adhere to this rubric in different ways. But they also all exhibit certain qualities of design, and they all adhere to a set of shared principles. What I will outline in the following pages are the three bits of guidance listed above, as well as how each pattern respects:

• Strong cohesion
• Proper coupling
• Robust encapsulation
• Avoiding redundancy
• Testability

In addition, I will submit that each pattern follows good principles in design, such as open-closed, the separation of concerns, and others.

I'll start with the definitions, then examine the patterns.

Design to Interfaces

Behavior in object-oriented systems is a reflection of the interaction of objects. If you change the objects or alter their interactions, the resulting behavior changes.

This means that objects have relationships to other objects, usually through references that are used to call methods. The GoF recommends that these relationships are defined based on how the objects look to each other, not by how the objects are implemented.

It's easy to misinterpret this to mean “every object should have a separate interface,” referring to the type “interface” that many languages provide. But the advice was not meant to indicate any language-specific idiom.

An “interface” means any defined means of communication. A method signature is an interface; the collective public methods of a class are an interface; an abstract class is an interface; etc. What is meant by that is the interface of any interaction should be based on what is needed by the clients and not the way the behavior is implemented. Changing the implementation should not affect the interface, and thus should not affect the clients.

In other words, the full version of this is “design to interfaces (how you work with them) rather than implementations (what each actually does).”

Favor Composition Over Inheritance

Composition/aggregation indicates a “has-a” relationship between objects. Inheritance, on the other han...

Table of contents

• Cover Page
• Title Page
• Copyright Page
• Table of Contents
• Introduction from the Author
• What Design Patterns Represent
• Design to Interfaces
• Favor Composition over Inheritance
• Encapsulate the Concept that Varies
• Qualities, Principles, Practices
• Qualities Patterns Share: Strong Cohesion
• Qualities Patterns Share: Proper Coupling
• Qualities Patterns Share: Avoiding Redundancy
• Qualities Patterns Share: Robust Encapsulation
• Qualities Patterns Share: Testability
• Principles Patterns Follow: Open-Closed
• Principles Patterns Follow: Liskov Substitution
• Principles Patterns Follow: Dependency Inversion
• Principles Patterns Follow: Separation of Concerns
• The Patterns Themselves
• The Abstract Factory
• The Adapter
• The Bridge
• The Builder
• The Chain of Responsibility
• The Composite
• The Decorator
• The Facade
• The Flyweight
• The Mediator
• The Memento
• The Mock Object
• The Null Object
• The Object Pool
• The Observer
• The Proxy
• The Singleton
• The Strategy
• The State
• The Template Method
• The Visitor
• Practice: Programming by Intention
• Practice: Encapsulate Constructors in Simple Classes
• Practice: Encapsulate by Policy, Reveal by Need
• Practice: Adhere to a Coding Standard
• Acknowledgments
• References