Master Design Patterns: Principles and All 3 Types Explained

Design Principles

1. Single Responsibility Principle : A class should have only one reason to change, meaning it should have only one responsibility.

2. Open‑Closed Principle : Software entities should be open for extension but closed for modification, achieved through interfaces and abstract classes.

3. Liskov Substitution Principle : Subtypes must be substitutable for their base types without altering program correctness.

4. Dependency Inversion Principle : Depend on abstractions, not on concrete implementations, reducing coupling between modules.

5. Interface Segregation Principle : Prefer many specific interfaces over a single general one to keep clients from depending on unused methods.

6. Composite Reuse Principle : Favor composition/aggregation over inheritance to reuse existing objects.

7. Demeter Principle (Least Knowledge) : Each unit should know as little as possible about other units, limiting communication scope.

Creational Patterns

Abstract Factory : Provides an interface for creating families of related objects without specifying concrete classes.

AbstractFactory – defines creation methods.

ConcreteFactory – implements those methods for a specific product family.

AbstractProduct – common product interface.

ConcreteProduct – concrete implementations.

Builder : Separates construction of a complex object from its representation, allowing the same construction process to create different representations.

Builder – abstract builder interface.

ConcreteBuilder – builds and assembles parts.

Director – orchestrates the building process.

Product – final complex object.

Factory Method : Defines an interface for creating an object, but lets subclasses decide which class to instantiate.

Product – abstract product.

ConcreteProduct – concrete product.

Creator – declares factory method.

ConcreteCreator – implements factory method.

Prototype : Creates new objects by cloning an existing prototype, reducing the cost of creating complex objects.

Prototype – declares cloning method.

ConcretePrototype – implements cloning.

Client – uses prototype to create new instances.

Singleton : Ensures a class has only one instance and provides a global access point.

Singleton – the sole instance with private constructor.

Structural Patterns

Adapter : Converts the interface of a class into another interface clients expect, allowing incompatible interfaces to work together.

Target – desired interface.

Adapter – implements Target and uses Adaptee.

Adaptee – existing class with incompatible interface.

Client – uses Target.

Bridge : Decouples an abstraction from its implementation so the two can vary independently.

Abstraction – high‑level control.

RefinedAbstraction – extends Abstraction.

Implementor – interface for implementation.

ConcreteImplementor – concrete implementation.

Composite : Composes objects into tree structures to represent part‑whole hierarchies; clients treat individual objects and compositions uniformly.

Component – common interface for leaf and composite.

Leaf – end objects.

Composite – containers of components.

Decorator : Adds responsibilities to objects dynamically without affecting other objects.

Component – abstract component.

ConcreteComponent – original object.

Decorator – abstract decorator.

ConcreteDecorator – adds behavior.

Facade : Provides a unified interface to a set of interfaces in a subsystem, simplifying client interaction.

Facade – single entry point.

Subsystem – underlying components.

Flyweight : Shares common parts of state among many objects to reduce memory usage.

Flyweight – shared interface.

ConcreteFlyweight – implements shared state.

UnsharedConcreteFlyweight – objects not shared.

FlyweightFactory – creates and manages flyweights.

Proxy : Provides a surrogate or placeholder for another object to control access to it.

Subject – common interface.

RealSubject – actual object.

Proxy – controls access to RealSubject.

Behavioral Patterns

Chain of Responsibility : Passes a request along a chain of handlers until one handles it.

Handler – abstract handler.

ConcreteHandler – handles or forwards request.

Client – initiates request.

Command : Encapsulates a request as an object, allowing parameterization and queuing of requests.

Command – abstract command.

ConcreteCommand – binds action to receiver.

Invoker – triggers command.

Receiver – performs the action.

Interpreter : Defines a grammar for a language and an interpreter to evaluate sentences in the language.

AbstractExpression – declares interpret operation.

TerminalExpression – implements terminal symbols.

NonterminalExpression – implements non‑terminal symbols.

Context – global information.

Client – uses interpreter.

Iterator : Provides a way to access elements of an aggregate object sequentially without exposing its underlying representation.

Iterator – abstract iterator.

ConcreteIterator – implements traversal.

Aggregate – abstract collection.

ConcreteAggregate – creates iterator.

Mediator : Defines an object that encapsulates how a set of objects interact, promoting loose coupling.

Mediator – abstract mediator.

ConcreteMediator – coordinates colleagues.

Colleague – abstract colleague.

ConcreteColleague – interacts via mediator.

Memento : Captures and externalizes an object's internal state so it can be restored later without violating encapsulation.

Originator – creates and restores state.

Memento – stores state.

Caretaker – manages mementos.

Observer : Defines a one‑to‑many dependency so that when one object changes state, all its dependents are notified.

Subject – maintains observers.

Observer – interface for notification.

ConcreteSubject – concrete subject.

ConcreteObserver – concrete observer.

State : Allows an object to alter its behavior when its internal state changes.

Context – maintains state reference.

State – abstract state.

ConcreteState – implements behavior for a state.

Strategy : Defines a family of algorithms, encapsulates each one, and makes them interchangeable.

Context – uses a Strategy.

Strategy – abstract algorithm.

ConcreteStrategy – specific algorithm.

Template Method : Defines the skeleton of an algorithm in a method, deferring some steps to subclasses.

AbstractClass – defines template method.

ConcreteClass – implements primitive operations.

Visitor : Represents an operation to be performed on elements of an object structure without changing the classes of the elements.

Visitor – abstract visitor.

ConcreteVisitor – implements operations.

Element – accepts visitor.

ConcreteElement – concrete element.

ObjectStructure – aggregates elements.