Introduction
Design patterns are proven, reusable solutions to common software design problems. When you apply object-oriented programming (OOP) principles like encapsulation, inheritance, and polymorphism, design patterns help you structure your Java applications more cleanly and robustly.
From creational to structural to behavioral categories, understanding these patterns is essential for writing professional-grade Java code.
This guide breaks down object-oriented design patterns using real-world Java examples and teaches you when and why to use each.
What Are Design Patterns?
Design patterns are blueprints for solving recurring design problems in a standardized, language-agnostic way. They’re not copy-paste code but guidelines.
Originating from the Gang of Four (GoF) book, design patterns fall into three categories:
- Creational: Object creation mechanisms
- Structural: Composition and relationships
- Behavioral: Communication between objects
Why Design Patterns Matter in OOP
- Encourage reusability
- Improve maintainability
- Simplify refactoring
- Promote SOLID design principles
- Enhance collaboration via shared vocabulary
Creational Patterns
1. Singleton
Ensures a class has only one instance.
public class Singleton {
private static final Singleton INSTANCE = new Singleton();
private Singleton() {}
public static Singleton getInstance() {
return INSTANCE;
}
}
📌 Use when: You need global state (e.g., logging, config).
2. Factory Method
Delegates object creation to subclasses.
interface Vehicle {
void drive();
}
class Car implements Vehicle {
public void drive() {
System.out.println("Car driving...");
}
}
class VehicleFactory {
public static Vehicle getVehicle(String type) {
if (type.equals("car")) return new Car();
return null;
}
}
📌 Use when: You want to abstract object instantiation logic.
3. Builder
Builds complex objects step-by-step.
class User {
private String name;
private int age;
public static class Builder {
private String name;
private int age;
public Builder setName(String name) {
this.name = name;
return this;
}
public Builder setAge(int age) {
this.age = age;
return this;
}
public User build() {
return new User(this);
}
}
private User(Builder builder) {
this.name = builder.name;
this.age = builder.age;
}
}
📌 Use when: You need immutable objects or many constructor params.
Structural Patterns
4. Adapter
Allows incompatible interfaces to work together.
interface MediaPlayer {
void play(String file);
}
class MP3Player {
void playMP3(String file) {
System.out.println("Playing MP3: " + file);
}
}
class MP3Adapter implements MediaPlayer {
private MP3Player player = new MP3Player();
public void play(String file) {
player.playMP3(file);
}
}
📌 Use when: Integrating legacy systems or incompatible APIs.
5. Composite
Treats individual objects and compositions uniformly.
interface Shape {
void draw();
}
class Circle implements Shape {
public void draw() { System.out.println("Circle"); }
}
class Drawing implements Shape {
private List<Shape> shapes = new ArrayList<>();
public void draw() {
for (Shape shape : shapes) shape.draw();
}
public void add(Shape s) { shapes.add(s); }
}
📌 Use when: You need to work with trees or hierarchies.
Behavioral Patterns
6. Strategy
Selects behavior at runtime.
interface PaymentStrategy {
void pay(double amount);
}
class CreditCardPayment implements PaymentStrategy {
public void pay(double amount) {
System.out.println("Paid by credit card: " + amount);
}
}
class PaymentProcessor {
private PaymentStrategy strategy;
public PaymentProcessor(PaymentStrategy strategy) {
this.strategy = strategy;
}
void process(double amount) {
strategy.pay(amount);
}
}
📌 Use when: You need to swap behavior dynamically.
7. Observer
Defines a one-to-many relationship.
interface Observer {
void update(String message);
}
class EmailSubscriber implements Observer {
public void update(String message) {
System.out.println("Email: " + message);
}
}
class Publisher {
List<Observer> observers = new ArrayList<>();
void subscribe(Observer o) { observers.add(o); }
void notifyAllObservers(String msg) {
for (Observer o : observers) o.update(msg);
}
}
📌 Use when: One change should trigger updates across other objects.
UML-Style Overview
<<interface>> Strategy
↑
CreditCardPayment, PayPalPayment
<<class>> PaymentProcessor
- strategy: Strategy
+ process(amount)
<<interface>> Observer
↑
EmailSubscriber, SmsSubscriber
<<class>> Publisher
- observers: List<Observer>
+ notifyAllObservers()
Refactoring Examples
Without Pattern
class AuthService {
void login(String type) {
if (type.equals("google")) { /* ... */ }
if (type.equals("facebook")) { /* ... */ }
}
}
✅ With Strategy Pattern
interface LoginStrategy {
void login();
}
class GoogleLogin implements LoginStrategy { public void login() {} }
class FacebookLogin implements LoginStrategy { public void login() {} }
class AuthService {
private LoginStrategy strategy;
AuthService(LoginStrategy s) { this.strategy = s; }
void login() { strategy.login(); }
}
Common Pitfalls
- Overusing patterns in simple scenarios
- Violating Single Responsibility when combining too many roles
- Using inheritance instead of composition
- Tight-coupling through poorly implemented patterns
Java 17/21 Notes
- Use sealed classes for Strategy or Observer if extension needs control
- Combine records with Builder or Strategy for value objects
- Use switch expressions + pattern matching as lightweight alternative to Strategy (Java 21+)
Best Practices
- Understand the problem before reaching for a pattern
- Don’t force patterns—use them where they naturally fit
- Use composition over inheritance
- Start with the simplest design and evolve
- Favor interface-based design to support DIP and ISP
Real-World Analogy
- Strategy is like choosing different payment methods at checkout
- Observer is like subscribing to a YouTube channel—new videos trigger notifications
- Builder is like building a customized pizza step-by-step
Conclusion
Object-oriented design patterns bring structure, clarity, and extensibility to your Java code. They are tools—not rules—that help you express your designs more clearly, solve problems consistently, and communicate effectively with other developers.
By mastering these patterns, you elevate your coding from functional to architectural.
Key Takeaways
- Use design patterns to solve recurring problems in a clean, proven way
- Pick the right pattern based on your design need
- Patterns encourage clean code, decoupling, and testability
- Start small—master core patterns like Strategy, Factory, and Observer
- Combine patterns with SOLID principles for scalable architectures
FAQs
1. Do I need to learn all 23 GoF patterns?
No, start with the 6–8 most commonly used ones like Strategy, Singleton, and Factory.
2. Can I mix multiple patterns together?
Yes, real systems often use pattern combinations.
3. Is using a pattern always the right solution?
No. Use patterns where they simplify—not complicate—the design.
4. Do patterns impact performance?
Some may introduce overhead. Optimize when needed.
5. Are design patterns language-specific?
No, but implementations may vary by language.
6. Can I use functional interfaces with design patterns in Java?
Yes, especially with Strategy and Command using lambdas.
7. What’s the difference between Factory and Builder?
Factory abstracts object creation; Builder assembles parts step-by-step.
8. Is Singleton considered an anti-pattern?
It can be if overused—consider DI as an alternative.
9. How do sealed classes help with patterns?
They control inheritance and improve pattern safety (e.g., for State/Strategy).
10. Can IDEs auto-generate design patterns?
Some can, but understanding their purpose is more important than generation.