150 Design Patterns: A Complete Guide
DataScienceQA Comprehensive Guide to 150 Concepts in Software Design Patterns
What are Design Patterns?
In software engineering, a design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source code. Rather, it is a description or template for how to solve a problem that can be used in many different situations. Patterns are formalized best practices that a programmer can use to solve common problems when designing an application or system. They help to create more flexible, reusable, and maintainable code.
Use Cases for Design Patterns:
Design patterns are used across all domains of software development to manage complexity and improve code quality.
• Application Architecture: Building the foundational structure of applications (e.g., using MVC or Microservices).
• Framework Development: Frameworks like Django, Spring, or Angular are built using a multitude of design patterns (e.g., Observer, Factory, Singleton).
• GUI Development: Handling events and component interactions (e.g., Command, Observer).
• Game Development: Managing game objects, states, and behaviors (e.g., State, Prototype, Command).
• Enterprise Systems: Dealing with database interactions, object creation, and complex business logic (e.g., Repository, Factory, Strategy).
Alternatives to Design Patterns:
While patterns are a powerful tool, they are not the only approach to software design.
• Ad-hoc / Emergent Design: For very simple or short-lived projects (like scripts or prototypes), a formal design is often overkill. The design emerges as the code is written. This is faster initially but does not scale well and leads to "technical debt."
• Framework-Driven Development: Instead of choosing patterns yourself, you can adopt a powerful, opinionated framework (e.g., Ruby on Rails, Django). The framework has already implemented many patterns and made design decisions for you. You solve problems by adhering to the "framework's way."
• Functional Programming Paradigm: Many design patterns are solutions to problems common in Object-Oriented Programming (like managing state). Functional programming offers an alternative approach by emphasizing immutability and pure functions, which can eliminate the need for certain patterns (like Iterator or Memento) while introducing its own set of patterns (like Monads or Functors).
---
Part 1: Foundational Principles (SOLID)
• S - Single Responsibility Principle (SRP)
Explanation: A class should have only one reason to change, meaning it should have only one job.
# Bad: This class does two things (user management and logging)
class User:
def save(self): pass
def log_error(self, error): pass
# Good: Separate responsibilities
class User:
def save(self): pass
class Logger:
def log_error(self, error): pass• O - Open/Closed Principle (OCP)
Explanation: Software entities (classes, modules) should be open for extension, but closed for modification.
# Bad: Modifying the class to add new shapes
class AreaCalculator:
def calculate_area(self, shape):
if shape.type == 'circle': return 3.14 * shape.radius**2
if shape.type == 'square': return shape.side**2
# Good: Extend with new shape classes without changing the calculator
class Shape: def area(self): raise NotImplementedError
class Circle(Shape): def area(self): ...
class Square(Shape): def area(self): ...
def calculate_area(shape: Shape): return shape.area()• L - Liskov Substitution Principle (LSP)
Explanation: Subtypes must be substitutable for their base types without altering the correctness of the program.
# Bad: A Penguin is a Bird, but it can't fly, breaking the contract.
class Bird: def fly(self): pass
class Penguin(Bird): def fly(self): raise Exception("Penguins can't fly!")
# Good: Better hierarchy
class Bird: pass
class FlyingBird(Bird): def fly(self): pass
class Penguin(Bird): pass # No fly method• I - Interface Segregation Principle (ISP)
Explanation: No client should be forced to depend on methods it does not use. Make fine-grained interfaces.
# Bad: A Robot is forced to implement `eat`.
class Worker:
def work(self): pass
def eat(self): pass
class Robot(Worker):
def work(self): print("Working...")
def eat(self): pass # Useless
# Good: Segregated interfaces
class Workable: def work(self): pass
class Eatable: def eat(self): pass
class Robot(Workable): ...
class Human(Workable, Eatable): ...• D - Dependency Inversion Principle (DIP)
Explanation: High-level modules should not depend on low-level modules. Both should depend on abstractions.
# Bad: High-level policy depends on low-level database details.
class ReportGenerator:
def __init__(self):
self.db = MySQLDatabase() # Concrete dependency
# Good: Depends on an abstraction (interface).
class Database: def query(self): pass
class ReportGenerator:
def __init__(self, db: Database): # Depends on abstraction
self.db = dbPart 2: Other Core Principles
• DRY - Don't Repeat Yourself
Explanation: Avoid duplicating code. Abstract common logic into a single place.
# Bad
print(f"User {user1.name} with email {user1.email}")
print(f"User {user2.name} with email {user2.email}")
# Good
def print_user_details(user):
print(f"User {user.name} with email {user.email}")
print_user_details(user1)
print_user_details(user2)• KISS - Keep It Simple, Stupid
Explanation: Favor simplicity in your design. Avoid unnecessary complexity.
# Bad: Overly complex for a simple task
is_even = lambda x: True if x % 2 == 0 else False
# Good: Simple and direct
def is_even(num):
return num % 2 == 0• YAGNI - You Aren't Gonna Need It
Explanation: Do not add functionality until it is deemed necessary.
# Bad: Adding a complex export feature that nobody has asked for yet.
class Report:
def to_html(self): pass
def to_pdf(self): pass
def to_xml(self): pass # YAGNI?
# Good: Start with the minimum required features.
class Report:
def to_html(self): passPart 3: Creational Patterns
• Pattern: Singleton
Explanation: Ensures a class has only one instance and provides a global point of access to it.
class DatabaseConnection:
_instance = None
def __new__(cls):
if cls._instance is None:
cls._instance = super().__new__(cls)
return cls._instance
db1 = DatabaseConnection()
db2 = DatabaseConnection()
# db1 is db2 will be True• Singleton: Use Case
Explanation: Useful for managing shared resources like database connections, loggers, or configuration settings.
• Singleton: Drawback
Explanation: Acts like a global variable, making code harder to test and potentially hiding dependencies.
• Pattern: Factory Method
Explanation: Defines an interface for creating an object, but lets subclasses alter the type of objects that will be created.
class Animal: pass
class Dog(Animal): pass
class Cat(Animal): pass
def get_animal(pet="dog") -> Animal:
"""This is the factory method."""
if pet == "dog":
return Dog()
if pet == "cat":
return Cat()• Factory Method: Intent
Explanation: To delegate the instantiation logic to child classes.
• Factory Method: Analogy
Explanation: A logistics company (Creator) decides which mode of transport (Product: Truck, Ship) to use.
• Pattern: Abstract Factory
Explanation: Provides an interface for creating families of related or dependent objects without specifying their concrete classes.
# Abstract Factory for UI elements
class UIFactory:
def create_button(self): pass
def create_checkbox(self): pass
class WindowsFactory(UIFactory): ... # Creates Windows-style widgets
class MacFactory(UIFactory): ... # Creates Mac-style widgets• Abstract Factory: Intent
Explanation: To create objects that belong to a common theme (e.g., all Modern UI widgets vs. all Antique UI widgets).
• Abstract Factory: Benefit
Explanation: Isolates client code from concrete implementation details of the products.
• Pattern: Builder
Explanation: Separates the construction of a complex object from its representation, so the same construction process can create different representations.
class Pizza:
def __init__(self): self.toppings = []
def add_topping(self, topping): self.toppings.append(topping)
class PizzaBuilder:
def __init__(self): self.pizza = Pizza()
def add_cheese(self): self.pizza.add_topping("cheese"); return self
def add_pepperoni(self): self.pizza.add_topping("pepperoni"); return self
def build(self): return self.pizza
pizza = PizzaBuilder().add_cheese().add_pepperoni().build()• Builder: Intent
Explanation: To construct complex objects step by step.
• Builder: Use Case
Explanation: Useful for creating objects with many optional parameters or configurations (e.g., an HTTP request).
• Pattern: Prototype
Explanation: Specifies the kinds of objects to create using a prototypical instance, and creates new objects by copying this prototype.
import copy
class Sheep:
def __init__(self, name): self.name = name
def clone(self): return copy.deepcopy(self)
original_sheep = Sheep("Dolly")
cloned_sheep = original_sheep.clone()• Prototype: Intent
Explanation: To create new objects by cloning, which can be more efficient than creating them from scratch.
• Prototype: Use Case
Explanation: Commonly used in game development to clone pre-configured enemies or objects.
Part 4: Structural Patterns
• Pattern: Adapter
Explanation: Allows objects with incompatible interfaces to collaborate.
class OldSystem: def specific_request(self): return "old data"
class NewSystemInterface: def request(self): pass
class Adapter(NewSystemInterface):
def __init__(self, old_system: OldSystem): self.old_system = old_system
def request(self): return self.old_system.specific_request()
# Client can now use the old system via the new interface.• Adapter: Analogy
Explanation: A travel power adapter that lets you plug your device's plug into a different type of wall socket.
• Pattern: Bridge
Explanation: Decouples an abstraction from its implementation so that the two can vary independently.
# Abstraction: RemoteControl
# Implementation: Device (TV, Radio)
class RemoteControl:
def __init__(self, device): self.device = device
def turn_on(self): self.device.power_on()
class AdvancedRemote(RemoteControl):
def mute(self): self.device.set_volume(0)
# The remote hierarchy is separate from the device hierarchy.• Bridge: Intent
Explanation: To avoid a "Cartesian product" explosion of classes when you have multiple dimensions of variation.
• Pattern: Composite
Explanation: Composes objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
# Component interface
class Graphic: def draw(self): pass
# Leaf
class Circle(Graphic): def draw(self): print("Drawing Circle")
# Composite
class Picture(Graphic):
def __init__(self): self.children = []
def add(self, graphic): self.children.append(graphic)
def draw(self):
for child in self.children: child.draw()• Composite: Use Case
Explanation: GUI frameworks (a window contains panels, which contain buttons) or file systems (a directory contains files and other directories).
• Pattern: Decorator
Explanation: Attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.
class Coffee: def cost(self): return 5
class MilkDecorator:
def __init__(self, coffee): self._coffee = coffee
def cost(self): return self._coffee.cost() + 2
my_coffee = Coffee()
my_coffee_with_milk = MilkDecorator(my_coffee)
# my_coffee_with_milk.cost() returns 7• Decorator: Analogy
Explanation: Adding toppings to a pizza. The base pizza is the object, and each topping is a decorator.
• Decorator vs. Subclassing
Explanation: Decorators add behavior at runtime, whereas subclassing adds it at compile time.
• Pattern: Facade
Explanation: Provides a simplified, higher-level interface to a complex subsystem of classes.
class AudioSystem: def setup(self): pass
class VideoSystem: def setup(self): pass
class LightSystem: def setup(self): pass
class HomeTheaterFacade:
def __init__(self):
self.audio = AudioSystem()
self.video = VideoSystem()
def watch_movie(self):
self.audio.setup()
self.video.setup()• Facade: Intent
Explanation: To make a complex system easier to use.
• Pattern: Flyweight
Explanation: Used to minimize memory usage by sharing as much data as possible with other similar objects.
# Flyweight: shared, intrinsic state (character type)
class CharacterType:
def __init__(self, font, size, color): ...
# Flyweight Factory
class CharacterFactory:
_types = {}
def get_type(self, font, size, color):
# Reuse existing type if available
...
# Context: unshared, extrinsic state (position on screen)
class Character:
def __init__(self, char_type, x, y): ...• Flyweight: Use Case
Explanation: Rendering millions of similar objects in a game (e.g., trees) or characters in a text editor.
• Pattern: Proxy
Explanation: Provides a surrogate or placeholder for another object to control access to it.
class RealImage:
def __init__(self, filename): self.load_from_disk(filename)
def display(self): ...
class ProxyImage: # A virtual proxy
def __init__(self, filename):
self.filename = filename
self._real_image = None
def display(self):
if self._real_image is None:
self._real_image = RealImage(self.filename) # Load on demand
self._real_image.display()• Proxy: Types
Explanation: Virtual Proxy (lazy loading), Protection Proxy (controls access), Remote Proxy (represents an object in a different address space).
Part 5: Behavioral Patterns
• Pattern: Chain of Responsibility
Explanation: Avoids coupling the sender of a request to its receiver by giving more than one object a chance to handle the request.
class Handler:
def set_next(self, handler): ...
def handle(self, request): ...
class AuthHandler(Handler): ...
class LoggingHandler(Handler): ...
# Chain: auth -> logging
auth = AuthHandler()
auth.set_next(LoggingHandler())
auth.handle("my_request")• Chain of Responsibility: Use Case
Explanation: Middleware in web frameworks (e.g., authentication, logging, caching).
• Pattern: Command
Explanation: Encapsulates a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.
class Command: def execute(self): pass
class LightOnCommand(Command):
def __init__(self, light): self.light = light
def execute(self): self.light.turn_on()
class RemoteControl:
def set_command(self, command): self.command = command
def press_button(self): self.command.execute()• Command: Use Case
Explanation: Implementing "undo/redo" functionality, queuing tasks, or GUI buttons.
• Pattern: Iterator
Explanation: Provides a way to access the elements of an aggregate object (e.g., a list) sequentially without exposing its underlying representation.
# In Python, this is built-in with iterators and generators.
my_list = [1, 2, 3]
it = iter(my_list) # The iterator object
next(it) # 1
next(it) # 2• Pattern: Mediator
Explanation: Defines an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly.
class ChatRoomMediator:
def show_message(self, user, message): ...
class User:
def __init__(self, name, mediator):
self.name = name
self.mediator = mediator
def send(self, message):
self.mediator.show_message(self, message)
# Users only know about the ChatRoom, not each other.• Mediator: Analogy
Explanation: An air traffic control tower. Pilots (colleagues) communicate with the tower (mediator), not with each other directly.
• Pattern: Memento
Explanation: Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later.
class Editor: # Originator
def create_state(self): return Memento(self.content)
def restore(self, memento): self.content = memento.get_state()
class Memento: # The Memento
def __init__(self, state): self._state = state
def get_state(self): return self._state
# Caretaker (not shown) holds the list of mementos.• Memento: Use Case
Explanation: Implementing "save/load" or "undo/redo" features in an application.
• Pattern: Observer
Explanation: Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
class Subject: # The publisher
def register(self, observer): ...
def notify(self): ...
class Observer: # The subscriber
def update(self, data): ...
# A news agency (Subject) notifies subscribers (Observers) of new articles.• Observer: Use Case
Explanation: Event handling systems in GUI frameworks, or implementing "publish/subscribe" systems.
• Pattern: State
Explanation: Allows an object to alter its behavior when its internal state changes. The object will appear to change its class.
class State: def handle(self): pass
class OnState(State): ...
class OffState(State): ...
class LightSwitch: # Context
def __init__(self): self.state = OffState()
def press(self):
# Delegates behavior to the current state object.
self.state.handle(self)• State vs. Strategy
Explanation: In State, the context changes its state object. In Strategy, the client provides the context with a strategy object.
• Pattern: Strategy
Explanation: Defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
class SortStrategy: def sort(self, data): pass
class BubbleSort(SortStrategy): ...
class QuickSort(SortStrategy): ...
class Sorter: # Context
def __init__(self, strategy): self.strategy = strategy
def execute_sort(self, data): self.strategy.sort(data)• Strategy: Analogy
Explanation: A map application allowing you to choose a route-finding strategy (fastest, shortest, avoid tolls).
• Pattern: Template Method
Explanation: Defines the skeleton of an algorithm in an operation, deferring some steps to subclasses.
class GameAI: # Abstract Class
def turn(self): # Template Method
self.collect_resources()
self.build_structures()
self.attack()
def collect_resources(self): ... # Common step
def build_structures(self): ... # Subclass implements this
def attack(self): ... # Subclass implements this• Template Method: Inversion of Control
Explanation: The high-level template method calls the low-level subclass implementations, not the other way around.
• Pattern: Visitor
Explanation: Represents an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.
class Shape: def accept(self, visitor): ...
class Circle(Shape): def accept(self, visitor): visitor.visit_circle(self)
class Visitor: def visit_circle(self, circle): ...
class AreaCalculatorVisitor(Visitor):
def visit_circle(self, circle): print("Calculating circle area")• Visitor: Benefit
Explanation: Excellent for adding new operations to a stable set of classes (e.g., exporting shapes to XML, JSON, etc.).
Part 6: Other Common Patterns
• Pattern: Dependency Injection
Explanation: A technique where one object supplies the dependencies of another object.
# Bad: Service creates its own dependency
class MyService:
def __init__(self): self.logger = Logger()
# Good: Dependency is "injected" from the outside
class MyService:
def __init__(self, logger: Logger):
self.logger = logger• DI: Benefit
Explanation: Greatly improves testability by allowing you to inject mock dependencies.
• Pattern: Repository
Explanation: Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.
class UserRepository:
def get_by_id(self, user_id): ...
def add(self, user): ...
def save(self, user): ...
# The rest of the app uses this repository, ignorant of the database.• Repository: Benefit
Explanation: Decouples business logic from data access logic (SQL, NoSQL, etc.).
• Pattern: Null Object
Explanation: Provides an object as a surrogate for the lack of an object of a given type. Avoids null references.
class User: def has_access(self): return True
class NullUser(User): def has_access(self): return False
def get_user(id):
# returns NullUser if user not found, instead of None
...
# Client code doesn't need to check for None
if get_user(123).has_access(): ...• Null Object: Benefit
Explanation: Simplifies client code by removing conditional checks for null or None.
Part 7: Architectural Patterns
• Pattern: Model-View-Controller (MVC)
Explanation: Separates an application into three interconnected components: Model (data), View (UI), and Controller (handles input).
• MVC: Model
Explanation: The central component, representing the application's data and business logic.
• MVC: View
Explanation: The presentation of the model in a particular format. The UI.
• MVC: Controller
Explanation: Receives user input and initiates a response by making calls on model objects.
• Pattern: Model-View-ViewModel (MVVM)
Explanation: An evolution of MVC, common in modern UI frameworks.
• MVVM: ViewModel
Explanation: A component that acts as a converter for the Model, transforming data into a format that the View can use easily. It handles the presentation logic.
• Pattern: Microservices
Explanation: An architectural style that structures an application as a collection of loosely coupled services.
• Microservices: Benefit
Explanation: Services can be developed, deployed, and scaled independently.
Part 8: Anti-Patterns (What to Avoid)
• Anti-Pattern: God Object
Explanation: A single, massive class that does everything and holds most of the program's state. Violates SRP.
• Anti-Pattern: Spaghetti Code
Explanation: Code that has a complex and tangled control structure, making it almost impossible to understand or maintain.
• Anti-Pattern: Lava Flow
Explanation: Features or code that are "frozen in place" because no one is sure what they do or what would break if they were removed.
• Anti-Pattern: Golden Hammer
Explanation: The tendency to use a familiar tool or pattern for every problem, even when it is not the best tool for the job.
(Continuing with more granular concepts and pattern details to reach 150)
• Creational Patterns: Core Idea - Concerned with the process of object creation.
• Structural Patterns: Core Idea - Explain how to assemble objects and classes into larger structures.
• Behavioral Patterns: Core Idea - Concerned with algorithms and the assignment of responsibilities between objects.
• Singleton: Thread Safety - A naive Singleton implementation is often not thread-safe.
• Factory Method: Parallel Hierarchies - Often results in a creator class hierarchy that mirrors the product class hierarchy.
• Abstract Factory: Product Families - The key concept is that a concrete factory creates objects that are designed to work together.
• Builder: Fluent Interface - The practice of returning self in methods to allow for chainable calls.
• Prototype: Shallow vs. Deep Copy - A shallow copy shares internal objects, while a deep copy duplicates everything. Prototypes often need deep copies.
• Adapter: Object vs. Class Adapter - Object Adapter uses composition (more common in Python), while Class Adapter uses multiple inheritance.
• Bridge: Abstraction - In the Bridge pattern, this is the high-level control layer for the client.
• Bridge: Implementation - This is the interface for the low-level platform-specific work.
• Composite: Uniformity - The key benefit is that clients can treat leaves and composites the same way.
• Decorator: Wrapper - A decorator is often called a "wrapper" because it wraps the original object.
• Facade: Simplification - Its main goal is to hide complexity, not to add functionality.
• Flyweight: Intrinsic State - The shared, immutable state stored in the flyweight object.
• Flyweight: Extrinsic State - The unshared, context-dependent state passed to the flyweight's methods by the client.
• Proxy: Subject Interface - Both the RealSubject and the Proxy implement the same interface.
• Chain of Responsibility: Loose Coupling - The sender does not know which object in the chain will handle the request.
• Command: Invoker - The object that holds a command and triggers its execution (e.g., a button or a menu item).
• Command: Receiver - The object that ultimately performs the action when the command is executed (e.g., a Light object).
• Iterator: Internal vs. External - An external iterator is controlled by the client (next()), while an internal iterator controls the iteration itself. Python's for loop is an example of using an internal iterator concept.
• Mediator: Colleague Objects - The objects that interact via the mediator. They do not know about each other.
• Memento: Originator - The object whose state needs to be saved. It creates the memento.
• Memento: Caretaker - The object that holds onto the memento but does not inspect or modify its content.
• Observer: Publisher/Subscriber - Another name for the Subject/Observer relationship.
• State: Context - The object whose behavior changes as its internal state object changes.
• Strategy: Context - The object that is configured with a concrete strategy object.
• Template Method: Abstract Class - The pattern is typically implemented with an abstract base class that defines the skeleton algorithm.
• Visitor: Double Dispatch - A technique used by the Visitor pattern where the operation depends on both the type of the visitor and the type of the element being visited.
• Pattern Language - A collection of related patterns that work together to solve a larger problem.
• Refactoring to Patterns - The process of modifying existing code to incorporate design patterns, improving its structure.
• Pattern Overuse - Applying patterns where they aren't needed can add unnecessary complexity (see Golden Hammer).
• GoF - Gang of Four - The authors of the seminal book "Design Patterns: Elements of Reusable Object-Oriented Software."
• Active Object Pattern - A concurrency pattern that decouples method execution from method invocation.
• Object Pool Pattern - A creational pattern used to reuse objects instead of creating new ones, often for performance reasons (e.g., database connections).
• Service Locator Pattern - A pattern that provides a central registry for services. Often considered an anti-pattern as it hides dependencies.
• Specification Pattern - A behavioral pattern used to encapsulate business logic for selecting objects.
• Lazy Initialization - A tactic (often used by Proxies or Singletons) of delaying the creation of an object until the first time it is needed.
• Eager Initialization - The opposite of lazy initialization, where an object is created at startup.
• Fluent API - An API designed to be highly readable, often implemented using method chaining (as seen in the Builder pattern).
• Monostate Pattern - An alternative to Singleton where all instances of a class share the same state, but there can be multiple instances.
• Anti-Pattern: Anemic Domain Model - Classes with state but no behavior (just getters and setters). The logic is handled by other service classes.
• Anti-Pattern: Magic Numbers - Unnamed numerical constants in code, making it hard to understand their purpose.
• Anti-Pattern: Premature Optimization - Optimizing code before it is necessary, often leading to more complex and less readable code.
• Interface - A contract defining a set of methods. In Python, this is often done with Abstract Base Classes (ABCs).
• Abstraction - The concept of hiding complex reality while exposing only the necessary parts. Many patterns rely on this.
• Encapsulation - Bundling data and the methods that operate on that data within one unit (a class).
• Composition - Building complex objects from simpler ones. Favored over inheritance ("Composition over Inheritance").
• Inheritance - A mechanism where a new class derives properties and behavior from an existing class.
• Polymorphism - The ability of an object to take on many forms. The draw() method on different Shape objects is an example.
• Coupling - The degree of interdependence between software modules. Patterns often aim to reduce coupling.
• Cohesion - The degree to which the elements inside a module belong together. Patterns aim to increase cohesion.
• Factory Function - A simpler alternative to the Factory Method pattern, using a standalone function instead of a class.
• Pythonic Decorators - Python's @ syntax is a direct implementation of the Decorator pattern for functions and methods.
• Python's __iter__ - The method that makes an object iterable, a key part of the Iterator pattern.
• Python's Context Managers (with statement) - Can be seen as a way to manage resources, similar to the Execute Around Method pattern.
• Inversion of Control (IoC) - A principle where the control flow of a program is inverted. Frameworks and Dependency Injection use this.
• Publisher - Another name for the Subject in the Observer pattern.
• Subscriber - Another name for the Observer in the Observer pattern.
• Pattern Intent - The core problem that the pattern is designed to solve.
• Pattern Motivation - A scenario that demonstrates the problem and how the pattern can solve it.
• Pattern Applicability - The situations in which the design pattern can be applied.
• Pattern Structure - A graphical representation of the classes and objects in the pattern.
• Pattern Participants - The classes and/or objects participating in the design pattern.
• Pattern Collaborations - How the participants collaborate to carry out their responsibilities.
• Pattern Consequences - The results, side effects, and trade-offs of using the pattern.
• Pattern Implementation - Pitfalls, hints, or techniques that should be kept in mind when implementing the pattern.
• Known Uses - Examples of the pattern found in real-world systems.
• Related Patterns - Other patterns that are similar or often used in conjunction with this one.
• Adapter vs. Bridge - Adapter makes things work after they're designed; Bridge makes them work before.
• Composite vs. Decorator - Both have similar structures, but Decorator adds responsibility, while Composite focuses on aggregation.
• Facade vs. Adapter - Facade defines a new, simpler interface; Adapter reuses an existing interface.
• Behavioral vs. Structural - Behavioral patterns focus on communication between objects; Structural patterns focus on their composition.
• MVC and Observer - The link between the Model and the View in MVC is often implemented using the Observer pattern.
• Strategy vs. Template Method - Strategy uses composition to change the entire algorithm; Template Method uses inheritance to change parts of it.
#DesignPatterns #SoftwareEngineering #Programming #OOP #CleanCode #SoftwareArchitecture