27.3. Classification of Design Patterns

Design patterns are broadly classified into three categories:

Design patterns can be categorized into three main types: Creational Patterns, Structural Patterns, and Behavioral Patterns. Each category addresses a specific kind of problem in software design. This classification helps developers choose the most appropriate pattern based on the situation they are dealing with.

Think of it like types of tools in a toolbox. Just as some tools are designed specifically for building (like screwdrivers & hammers), others might be for organizing (like bins) or for detailing (like sandpaper). In design patterns, some patterns help with creating objects, others help organize them, and some deal with how they interact.

1. Creational Patterns Deal with object creation mechanisms, trying to create objects in a manner suitable to the situation.

Creational patterns focus on the way objects are created, aiming to make the creation process more flexible and efficient. They allow incomplete object definitions to be resolved within the context, making it easier to create objects based on the specific requirements or context they are being created in.

Imagine you are in a restaurant. You want to order a dish, but the kitchen has many ways to cook it (grill, bake, steam). Depending on what you choose, it will be prepared differently. Creational patterns work similarly to help software define how to create an object based on what's needed at that moment.

• 27.3.1 Singleton Pattern Ensures a class has only one instance and provides a global point of access to it. Use Case: Configuration objects, logging, thread pools.

• 27.3.2 Factory Method Pattern Defines an interface for creating an object but lets subclasses alter the type of objects that will be created. Use Case: GUI libraries, frameworks requiring interchangeable components.

• 27.3.3 Abstract Factory Pattern Provides an interface for creating families of related or dependent objects without specifying their concrete classes. Use Case: Theme or skin factories in GUI apps.

• 27.3.4 Builder Pattern Separates the construction of a complex object from its representation. Use Case: Creating objects with multiple configurations (e.g., a meal, a document, or a house).

• 27.3.5 Prototype Pattern Creates new objects by copying an existing object, known as the prototype. Use Case: Game development (cloning characters), prototyping expensive objects.

Each specific creational pattern provides a different mechanism for object creation:

1. Singleton Pattern ensures only one instance of a class exists, which is useful for configuration settings where multiple instances could lead to inconsistencies.
2. Factory Method Pattern allows subclasses to create objects from a defined interface, making the code more flexible and easier to manage.
3. Abstract Factory Pattern creates families of related objects without specifying their classes, thus promoting consistency among products.
4. Builder Pattern abstracts the process of constructing complex objects into manageable parts, allowing for different representations.
5. Prototype Pattern allows creating new objects by copying existing ones, making it easier to create similar instances without complicated setups.

Imagine building a car. The Singleton Pattern is like having one factory that produces cars to ensure quality control. The Factory Method Pattern is like having different car models (sedan, SUV) that have a common interface (building process) but different parts. The Abstract Factory Pattern is akin to selling car packages that include engines, tires, and interiors specific to that vehicle. Builder Pattern lets you customize a car's features step by step (color, engine type), while Prototype Pattern allows you to make variations of a car model simply by copying an existing one.

2. Structural Patterns Concerned with the composition of classes and objects.

Structural patterns deal with how classes and objects map to each other, ensuring that various components of an application work seamlessly together. They focus on the composition of objects and typically help to form larger structures from smaller components, promoting flexibility and efficiency in design.

Think about building a LEGO set. Structural patterns are like the instructions provided that help you fit different LEGO pieces together. They ensure that each piece (class or object) fits correctly with others and can be structured in various ways without breaking the overall model.

• 27.3.6 Adapter Pattern Allows incompatible interfaces to work together. Use Case: Legacy code integration, plugin systems.

• 27.3.7 Bridge Pattern Decouples an abstraction from its implementation so that the two can vary independently. Use Case: Device-driver systems, UI abstraction.

• 27.3.8 Composite Pattern Composes objects into tree structures to represent part-whole hierarchies. Use Case: File system representation, GUI elements.

• 27.3.9 Decorator Pattern Adds behavior to objects dynamically without altering their structure. Use Case: GUI components (scrollbars, borders), I/O streams.

• 27.3.10 Facade Pattern Provides a simplified interface to a complex subsystem. Use Case: Libraries, frameworks with multiple subsystems.

• 27.3.11 Flyweight Pattern Reduces memory usage by sharing common parts of objects instead of duplicating them. Use Case: Text rendering, object pools in games.

• 27.3.12 Proxy Pattern Provides a surrogate or placeholder for another object to control access to it. Use Case: Remote proxies, virtual proxies, protection proxies.

Specific structural patterns include:

1. Adapter Pattern that allows two incompatible interfaces to work together, thus enabling legacy systems to integrate into newer frameworks.
2. Bridge Pattern allows the separation of abstraction from implementation, useful when changes are expected in either side.
3. Composite Pattern enables creating a tree structure that represents hierarchy effectively, useful for managing complex files or GUI elements.
4. Decorator Pattern is versatile for adding new features or functionalities to objects without altering their structure.
5. Facade Pattern simplifies interactions with complex subsystems by providing a more accessible interface.
6. Flyweight Pattern conserves memory by sharing common parts among objects rather than creating new instances of similar objects.
7. Proxy Pattern acts as a placeholder to control access to another object, which can be useful for optimization or protection.

Consider a bakery as an analogy. Adapter Pattern allows old equipment to work with new recipes seamlessly. The Bridge Pattern represents the separation of ingredients (baking) from the cooking method (oven or mixer). Composite Pattern builds a whole cake (with layers or decorations) as parts come together. Similarly, the Decorator Pattern lets you add toppings or icing without changing the underlying cake recipe. The Facade Pattern is like a shop that simplifies orders for customers from a complex baking process behind the scenes. The Flyweight Pattern allows reusing muffin cups, reducing waste, while the Proxy Pattern acts as a security front desk managing who can enter the bakery kitchen.

3. Behavioral Patterns Focus on communication between objects.

Behavioral patterns are concerned with the interaction and responsibility between objects. They help define how objects communicate and collaborate with one another, managing complex flows and processes through their collaboration. These patterns enable effective communication, coordination, and chaining of tasks among various components within a system.

Think of a symphony orchestra where different musicians (objects) have to work together harmoniously to create music. Each musician has a specific role and communicates through their instruments (based on behavioral patterns), presenting a cohesive and coordinated performance.

• 27.3.13 Chain of Responsibility Pattern Passes a request along a chain of handlers until one handles it. Use Case: Event handling systems, middleware.

• 27.3.14 Command Pattern Encapsulates a request as an object, allowing parameterization of clients. Use Case: Undo-redo systems, transactional systems.

• 27.3.15 Interpreter Pattern Defines a grammar and provides an interpreter to interpret sentences of the grammar. Use Case: SQL interpreters, expression evaluation.

• 27.3.16 Iterator Pattern Provides a way to access the elements of an aggregate object sequentially. Use Case: Collection libraries, data traversals.

• 27.3.17 Mediator Pattern Encapsulates how a set of objects interact. Use Case: Chat applications, component decoupling.

• 27.3.18 Memento Pattern Captures and restores an object’s internal state without violating encapsulation. Use Case: Save/restore functionality in games.

• 27.3.19 Observer Pattern Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified. Use Case: UI event handling, stock market feeds.

• 27.3.20 State Pattern Allows an object to alter its behavior when its internal state changes. Use Case: TCP connection states, UI form state changes.

• 27.3.21 Strategy Pattern Enables selecting an algorithm at runtime. Use Case: Sorting strategies, compression strategies.

• 27.3.22 Template Method Pattern Defines the program skeleton in a method but lets subclasses override specific steps. Use Case: Frameworks, algorithm structures.

• 27.3.23 Visitor Pattern Separates an algorithm from the object structure it operates on. Use Case: Compilers, document processing.

Specific behavioral patterns include:

1. Chain of Responsibility Pattern allows requests to be passed through a chain of handlers until one processes it, useful in event handling.
2. Command Pattern encapsulates a command in an object, allowing you to parameterize and queue requests, commonly seen in undo/redo functionalities.
3. Interpreter Pattern provides a way to parse sentences based on defined grammar, used in language processing like SQL interpreters.
4. Iterator Pattern allows sequential access to elements in a collection, helping with data traversals.
5. Mediator Pattern defines a simplified communication path between objects, ensuring loose coupling and coordination.
6. Memento Pattern captures an object’s state to enable restoring later without exposing internal structure, useful in applications like gaming.
7. Observer Pattern creates a setup where one object can notify multiple others, ideal for updating user interfaces based on changes.
8. State Pattern enables objects to act differently based on their internal state, making behavior dynamic.
9. Strategy Pattern lets algorithms be defined and selected at runtime, providing flexibility.
10. Template Method Pattern defines a skeleton for an algorithm while allowing subclasses to expand upon it.
11. Visitor Pattern separates an algorithm from the object structure it works on, which makes it easier to add new operations without modifying existing code.

In terms of interactions in a restaurant: the Chain of Responsibility Pattern acts like a waiter, who forwards orders to the kitchen staff until the appropriate chef handles it. The Command Pattern allows patrons to place customizable orders encompassing the entire dining experience, ready to be modified or retried. The Interpreter Pattern defines how to read menu items based on various customer needs. The Iterator Pattern lets waitstaff go through tables in a restaurant one by one, while the Mediator Pattern ensures that cooking staff communicate efficiently without each having to know every other's intricate detail. Memento Pattern allows for saving a customer’s last order, enabling easy repeatability. The Observer Pattern keeps diners updated on food arrival without needing to ask, while the State Pattern adjusts service levels based on busy meal times. The Strategy Pattern allows the chef to select cooking methods per diner preferences, while the Template Method Pattern helps in standardizing meals while allowing seasonal or personalized tweaks. Lastly, the Visitor Pattern lets new menu items be introduced without disrupting established recipe layouts.

--