Introduction: Why Design Patterns Matter
Facade Pattern (Structural)
Builder Pattern (Creational)
Strategy Pattern (Behavioral)
Comparative Matrix & Key Takeaways
Mastering Object-Oriented Design: Facade, Builder, and Strategy Patterns
Software development is rarely just about writing code that works; it is about writing code that remains maintainable, scalable, and adaptable over time. Object-Oriented Design Patterns represent proven, industry-tested solutions to common architectural challenges.
In this article, we will break down three essential patterns—Facade, Builder, and Strategy—exploring their real-world analogies, structural mechanics, advantages, pseudocode, and Java implementations.
Facade Pattern (Structural)
// Subsystem Components
class Engine {
public void start() {
System.out.println("Engine started successfully.");
}
}
class Ignition {
public void turnOn() {
System.out.println("Ignition switched ON.");
}
}
class FuelPump {
public void inject() {
System.out.println("Fuel pump pressurized and injected.");
}
}
// Facade Class
public class CarFacade {
private final Engine engine = new Engine();
private final Ignition ignition = new Ignition();
private final FuelPump fuelPump = new FuelPump();
public void startCar() {
ignition.turnOn();
fuelPump.inject();
engine.start();
}
}
// Execution
public class Main {
public static void main(String[] args) {
CarFacade car = new CarFacade();
car.startCar(); // Single entry point call
}
}
Overview & Core Concept
According to the principles of structural design, a system often grows complex as it scales, accumulating dozens of interconnected classes, subsystem initializations, and intricate execution flows. The Facade Pattern provides a simplified, high-level interface to a complex framework, library, or set of subsystem classes.
When to Use
When you need a limited, straightforward interface to a complex subsystem.
When you want to structure a subsystem into layers (using Facades as entry points for each layer).
Pros & Cons
Pros: Isolates your code from the complexity of a subsystem; decouples client code from third-party frameworks.
Cons: A Facade risks becoming a „God Object” coupled to all classes of an app if not kept focused.
Real-World Analogy
Imagine placing an order at a restaurant or initiating a home theater setup. You do not walk into the kitchen to chop vegetables, ignite the stove, or plate the dish. You simply tell the waiter what you want. The waiter acts as your Facade, shielding you from the internal operations of the kitchen.
// UML Diagram
Plaintext
+———————–+
| Client |
+———————–+
|
v
+———————–+
| CarFacade |
+———————–+
| | |
v v v
+—–+ +—–+ +———-+
|Engine| |Ignition| |FuelPump |
+—–+ +—–+ +———-+
Builder Pattern (Creational)
// Product Class
class Bicycle {
private String frame;
private String handlebars;
public void setFrame(String frame) { this.frame = frame; }
public void setHandlebars(String handlebars) { this.handlebars = handlebars; }
public void displayInfo() {
System.out.println("Bicycle Specs -> Frame: " + frame + " | Handlebars: " + handlebars);
}
}
// Builder Class
public class BicycleBuilder {
private final Bicycle bicycle = new Bicycle();
public BicycleBuilder setFrame(String frame) {
bicycle.setFrame(frame);
return this; // Enables Method Chaining
}
public BicycleBuilder setHandlebars(String handlebars) {
bicycle.setHandlebars(handlebars);
return this;
}
public Bicycle build() {
return bicycle;
}
}
// Execution
public class Main {
public static void main(String[] args) {
Bicycle customGravelBike = new BicycleBuilder()
.setFrame("Carbon Monocoque")
.setHandlebars("Flare Drop Bar")
.build();
customGravelBike.displayInfo();
}
}
Overview & Core Concept
According to the principles of structural design, a system often grows complex as it scales, accumulating dozens of interconnected classes, subsystem initializations, and intricate execution flows. The Facade Pattern provides a simplified, high-level interface to a complex framework, library, or set of subsystem classes.
When to Use
When you need a limited, straightforward interface to a complex subsystem.
When you want to structure a subsystem into layers (using Facades as entry points for each layer).
Pros & Cons
Pros: Isolates your code from the complexity of a subsystem; decouples client code from third-party frameworks.
Cons: A Facade risks becoming a „God Object” coupled to all classes of an app if not kept focused.
Real-World Analogy
Imagine placing an order at a restaurant or initiating a home theater setup. You do not walk into the kitchen to chop vegetables, ignite the stove, or plate the dish. You simply tell the waiter what you want. The waiter acts as your Facade, shielding you from the internal operations of the kitchen.
// UML Diagram
Client BicycleBuilder Bicycle
| | |
|— setFrame() ——>| |
|— setHandlebars()->| |
|— build() ——–>| |
| |— new Bicycle() –>|
|<– returns object –| |
Strategy Pattern (Behavioral)
// Strategy Interface
interface PaymentStrategy {
void pay(int amount);
}
// Concrete Strategy 1
class CreditCardPayment implements PaymentStrategy {
@Override
public void pay(int amount) {
System.out.println("Processing $" + amount + " payment via Credit Card.");
}
}
// Concrete Strategy 2
class PayPalPayment implements PaymentStrategy {
@Override
public void pay(int amount) {
System.out.println("Processing $" + amount + " payment via PayPal.");
}
}
// Context Class
public class ShoppingCart {
private PaymentStrategy strategy;
public void setPaymentStrategy(PaymentStrategy strategy) {
this.strategy = strategy;
}
public void checkout(int amount) {
if (strategy == null) {
System.out.println("Error: Please select a payment strategy first.");
return;
}
strategy.pay(amount);
}
}
// Execution
public class Main {
public static void main(String[] args) {
ShoppingCart cart = new ShoppingCart();
// Select and execute Credit Card strategy
cart.setPaymentStrategy(new CreditCardPayment());
cart.checkout(250);
// Dynamically switch strategy at runtime to PayPal
cart.setPaymentStrategy(new PayPalPayment());
cart.checkout(100);
}
}
Overview & Core Concept
The Strategy Pattern is a behavioral pattern that defines a family of algorithms, encapsulates each one into a separate class, and makes their objects interchangeable.
Instead of embedding multiple algorithms directly into a class using monolithic conditional statements (if/else or switch), Strategy extracts the algorithms into separate classes (strategies) that adhere to a common interface.
Real-World Analogy
Imagine traveling to an airport. Your goal is to get to the terminal, but your strategy can change based on context: you can drive a car, take a public bus, or ride a bicycle. The destination remains identical, but the execution method is swapped dynamically without changing the passenger’s itinerary.
When to Use
When you want to use different variants of an algorithm within an object and switch from one algorithm to another during runtime.
When you have a lot of similar classes that only differ in the way they execute some behavior.
To isolate the business logic of a class from the implementation details of algorithms.
Pros & Cons
Pros: You can swap algorithms used inside an object at runtime; adheres to the Open/Closed Principle (add new strategies without modifying context code); eliminates bulky conditional logic.
Cons: Clients must be aware of the differences between strategies to select the right one.
// UML Diagram
+———————–+
| ShoppingCart |
+———————–+
| – strategy: Interface |
+———————–+
|
v (delegates call)
+———————–+
| <<PaymentStrategy>> |
+———————–+
/ \
/ \
+—————-+ +——————+
| CreditCardPay | | PayPalPayment |
+—————-+ +——————+
Comparative Matrix & Key Takeaways
|
Pattern
|
Category
|
Primary Intent
|
Key Benefit
|
Real-World E-Commerce Example
|
|---|---|---|---|---|
