Comprehensive Overview of 23 Java Design Patterns

Purpose of Design Patterns

Design patterns are distilled solutions from past experience that guide developers toward high‑quality code by improving reusability, readability, extensibility, and reliability while reducing coupling between classes.

Four key benefits:

Code reuse: avoid writing the same functionality repeatedly.

Readability: make programs easier to understand and maintain.

Extensibility: support the Open/Closed principle, allowing new behavior without modifying existing code.

Reliability: new features do not break existing functionality.

Seven Common Design Principles

Single Responsibility Principle – a class should have only one responsibility.

Interface Segregation Principle – avoid forcing implementing classes to depend on unnecessary methods.

Dependency Inversion Principle – high‑level modules should depend on abstractions, not concrete implementations.

Liskov Substitution Principle – subclasses should be replaceable for their base classes without altering correctness.

Open/Closed Principle – software entities should be open for extension but closed for modification.

Law of Demeter – a class should know as little as possible about other classes.

Composite Reuse Principle – favor composition over inheritance.

Classification of Design Patterns

Design patterns are grouped into three categories:

Creational patterns – focus on object creation and separate creation from usage.

Structural patterns – deal with composing classes or objects into larger structures.

Behavioral patterns – describe communication between objects and responsibility allocation.

Creational Patterns (5)

1. Singleton

Ensures a class has only one instance throughout the application.

Typical uses: application configuration, database connection pool, Spring beans (default singleton), etc.

2. Factory Method

Defines an interface for creating an object (product) but lets subclasses decide which class to instantiate.

Use when object creation is complex or needs to be decoupled from client code.

3. Abstract Factory

Provides an interface for creating families of related or dependent objects without specifying concrete classes.

Common in UI theme switching, DAO layer supporting multiple databases, cross‑platform code.

4. Prototype

Creates new objects by cloning an existing prototype, useful when object creation is expensive.

Use cases: large‑scale initialization, protecting mutable objects via deep copy.

5. Builder

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

Typical scenarios: building a travel package, assembling a car, constructing complex UI components.

Structural Patterns (7)

1. Adapter

Converts one interface into another that a client expects, enabling incompatible classes to work together.

Use cases: legacy interface adaptation, unified payment APIs, compatibility layers.

2. Bridge

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

Example: JDBC driver bridging.

3. Decorator

Dynamically adds responsibilities to objects without affecting other objects.

Use for extending functionality at runtime, such as adding logging or security.

4. Composite

Composes objects into tree structures to represent part‑whole hierarchies (e.g., file systems, organization charts).

5. Facade

Provides a unified interface to a set of interfaces in a subsystem, simplifying usage.

6. Flyweight

Shares common parts of state among many fine‑grained objects to reduce memory consumption (e.g., connection pools).

7. Proxy

Provides a placeholder for another object to control access, add functionality, or defer creation.

Common uses: logging, access control, AOP, remote procedure calls, transaction management.

Behavioral Patterns (11)

1. Template Method

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

2. Command

Encapsulates a request as an object, separating the sender from the receiver.

3. Visitor

Separates an algorithm from the object structure it operates on, allowing new operations without changing the elements.

4. Iterator

Provides a way to access elements of a collection sequentially without exposing its underlying representation.

5. Observer

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

6. Mediator

Encapsulates how a set of objects interact, promoting loose coupling by keeping objects from referring to each other explicitly.

7. Memento

Captures and externalizes an object’s internal state without violating encapsulation, allowing the object to be restored later.

8. Interpreter

Given a language, defines a representation for its grammar and an interpreter to evaluate sentences in the language.

9. State

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

10. Strategy

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

11. Chain of Responsibility

Passes a request along a chain of handlers; each handler decides either to process the request or to forward it.

Conclusion

The article presents a complete, illustrated summary of 23 Java design patterns, providing definitions, core principles, and typical application scenarios to help developers read framework source code and design robust, maintainable systems.