Types of Design Patterns from GoF

GoF

The book Design Patterns: Elements of Reusable Object-Oriented Software is written by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. These four authors are known as the Gang of Four (GoF). This book is credited with launching patterns in the software world. It’s a well-organized document that divides a pattern into several sections: intent, motivation, applicability, structure, participants, collaborations, consequences, implementation, sample code, known uses, and related patterns, just to name a few. The GoF patterns are huge, with each one encompassing a dozen pages.

Types of patterns

The GoF has a collection of 23 design patterns. The patterns are divided into three main categories:

• Behavioral patterns: For defining how objects interact
• Creational patterns: For object creation
• Structural patterns: For object relationships

Behavioral patterns

Behavioral patterns describe how objects collaborate and distribute responsibilities.

• Template Method: Defines the skeleton of an algorithm in a superclass; subclasses override specific steps without changing the algorithm’s structure.
• Iterator: Provides a uniform interface to traverse elements of a collection without exposing its internal representation.

Creational patterns

Creational patterns focus on object creation, providing flexible ways to instantiate objects.

• Factory Method: Defines an interface for creating an object but lets subclasses decide which concrete class to instantiate. Use it when client code should depend on an abstraction, not specific classes.
• Singleton: Ensures a class has only one instance and provides a global access point to it. (Be mindful of concurrency and testability.)

Structural patterns

Structural patterns focus on composing objects and classes to form larger structures while keeping them flexible and efficient.

• Adapter: A structural pattern that converts the interface of a class into another interface clients expect, acting as a middleman between otherwise incompatible APIs. (Android “adapters” are a practical example but not the canonical GoF definition.)
• Bridge: A structural pattern that decouples an abstraction from its implementation so the two can vary independently (e.g., Shape ↔ DrawingAPI, RemoteControl ↔ Device).
  Note: If you’re simply choosing an algorithm at runtime (e.g., BFS vs Dijkstra vs A*), that’s the Strategy pattern, which is behavioral, not Bridge.