Important Design Patterns in a Nutshell

When building complex software systems, writing code that simply "works" is not enough. As systems scale and requirements evolve, poorly structured object creation, tight coupling, hardcoded control flows, and static inheritance hierarchies lead to fragile architectures.

This comprehensive guide breaks down five essential design patterns—Abstract Factory, Strategy, Adapter, Observer, and Decorator—with real-world enterprise scenarios, anti-patterns, trade-offs, and refactoring step-by-steps.

---

📊 Software Design Patterns Quick Reference Cheat Sheet

Pattern	Category	Core Intent	Real-World Scenario	Primary Advantage	Main Architectural Trade-Off
Abstract Factory	Creational	Creates families of related objects without specifying their concrete classes.	Multi-tier service bundles (e.g., Basic vs. Elite Tax Packages).	Eliminates product family mismatches; enforces cohesive object creation.	High interface proliferation and indirection overhead.
Strategy	Behavioral	Encapsulates interchangeable algorithms behind a unified interface.	Multi-gateway payment router (Stripe, PayPal, Adyen).	Removes monolithic if-else/switch blocks; adheres to Open/Closed Principle.	Class/module explosion for simple variant algorithms.
Adapter	Structural	Translates between two incompatible interfaces.	Onboarding service integrating legacy vendor KYC SDKs.	Isolates domain logic from external/legacy API changes.	Data mapping overhead and potential leaky abstractions.
Observer	Behavioral	Defines a 1-to-N dependency to broadcast state changes to subscribers.	Event notification on e-commerce order checkout.	Decouples domain core from downstream side-effects.	Obscured execution flow makes debugging and tracing harder.
Decorator	Structural	Dynamically adds behavior to an object at runtime without altering class structure.	Payment processing pipeline with optional fraud detection & auditing.	Avoids subclass permutation explosion; enables dynamic composition.	Breaches object identity (== checks fail); order dependence runtime risks.

---

1. Abstract Factory Pattern

Core Concept

The Abstract Factory pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes. It guarantees that a set of products designed to work together are instantiated as a cohesive unit, decoupling creation logic from consumer code.

Scenario: Tiered Tax Service Packages

Suppose a service provider offers two packaged service tiers:

1. Tax Filing Service: Basic (standard W-2) vs. Elite (multi-state, crypto, stock options).
2. Tax Saving Service: Basic (401k advice) vs. Elite (estate planning & offshore tax shelters).

❌ Violated Architecture: Scattered Instantiation & Family Mismatch Risk

Directly instantiating concrete products in business logic introduces human error—a developer could accidentally mix a BasicTaxFiling service with an EliteTaxSaving service.

public class TaxServiceOrchestrator {

    public void executeService(String tier) {
        TaxFilingService filing;
        TaxSavingService saving;

        // Prone to human error: a developer could accidentally mix BASIC filing with ELITE saving
        if ("BASIC".equalsIgnoreCase(tier)) {
            filing = new BasicTaxFiling();
            saving = new BasicTaxSaving();
        } else if ("ELITE".equalsIgnoreCase(tier)) {
            filing = new EliteTaxFiling();
            saving = new EliteTaxSaving();
        } else {
            throw new IllegalArgumentException("Invalid service tier: " + tier);
        }

        filing.fileTaxes();
        saving.provideAdvice();
    }
}

Enter fullscreen mode Exit fullscreen mode

---

✅ Refactored Architecture: Abstract Factory Enforcement

Structural Architecture Diagram

graph TD
    subgraph Client Code
        Orchestrator[TaxServiceOrchestrator]
    end

    subgraph Factory Hierarchy
        FactoryInterface[FullServicePackageFactory Interface]
        BasicFactory[BasicPackageFactory]
        EliteFactory[ElitePackageFactory]

        FactoryInterface <|-- BasicFactory
        FactoryInterface <|-- EliteFactory
    end

    subgraph Product Families
        FilingInterface[TaxFilingService]
        SavingInterface[TaxSavingService]

        BasicFiling[BasicTaxFiling]
        EliteFiling[EliteTaxFiling]
        BasicSaving[BasicTaxSaving]
        EliteSaving[EliteTaxSaving]

        FilingInterface <|-- BasicFiling
        FilingInterface <|-- EliteFiling
        SavingInterface <|-- BasicSaving
        SavingInterface <|-- EliteSaving
    end

    Orchestrator --> FactoryInterface
    BasicFactory ..> BasicFiling
    BasicFactory ..> BasicSaving
    EliteFactory ..> EliteFiling
    EliteFactory ..> EliteSaving

Enter fullscreen mode Exit fullscreen mode

Code Implementation

// 1. Abstract Product 1: Tax Filing
public interface TaxFilingService {
    void fileTaxes();
}

// 2. Abstract Product 2: Tax Saving
public interface TaxSavingService {
    void provideAdvice();
}

// 3. Concrete Products for BASIC Tier
public class BasicTaxFiling implements TaxFilingService {
    @Override
    public void fileTaxes() { 
        System.out.println("Filing standard W-2 income taxes."); 
    }
}

public class BasicTaxSaving implements TaxSavingService {
    @Override
    public void provideAdvice() { 
        System.out.println("Providing basic 401(k) contribution advice."); 
    }
}

// 4. Concrete Products for ELITE Tier
public class EliteTaxFiling implements TaxFilingService {
    @Override
    public void fileTaxes() { 
        System.out.println("Filing multi-state, crypto, and stock-option taxes."); 
    }
}

public class EliteTaxSaving implements TaxSavingService {
    @Override
    public void provideAdvice() { 
        System.out.println("Providing estate planning and offshore tax shelter advice."); 
    }
}

// 5. The Abstract Factory Interface
public interface FullServicePackageFactory {
    TaxFilingService createFilingService();
    TaxSavingService createSavingService();
}

// 6. Concrete Factory 1: Basic Package Family
public class BasicPackageFactory implements FullServicePackageFactory {
    @Override
    public TaxFilingService createFilingService() { 
        return new BasicTaxFiling(); 
    }

    @Override
    public TaxSavingService createSavingService() { 
        return new BasicTaxSaving(); 
    }
}

// 7. Concrete Factory 2: Elite Package Family
public class ElitePackageFactory implements FullServicePackageFactory {
    @Override
    public TaxFilingService createFilingService() { 
        return new EliteTaxFiling(); 
    }

    @Override
    public TaxSavingService createSavingService() { 
        return new EliteTaxSaving(); 
    }
}

// 8. Clean Client Code (Guaranteed family cohesion, zero risk of mixing tiers)
public class TaxOrchestrator {
    private final TaxFilingService filingService;
    private final TaxSavingService savingService;

    // Injected with a cohesive factory family
    public TaxOrchestrator(FullServicePackageFactory packageFactory) {
        this.filingService = packageFactory.createFilingService();
        this.savingService = packageFactory.createSavingService();
    }

    public void runFullService() {
        filingService.fileTaxes();
        savingService.provideAdvice();
    }
}

Enter fullscreen mode Exit fullscreen mode

Why Do We Need It?

• Eliminates Concrete Coupling: Decouples business logic from specific product classes.
• Extensibility: Simplifies adding new product lines/tiers without altering client business code.
• Prevents Product Mismatch: Enforces that instances created by a factory belong strictly to the same product family.
• SOLID Alignment: Adheres to the Open/Closed Principle and Dependency Inversion Principle.

Architectural Trade-offs

• Indirection Overhead: Developers must navigate through interfaces and factory abstractions to inspect underlying concrete instantiations.
• Interface Proliferation: Requires creating abstract interfaces for both factories and every product line introduced.

When to AVOID or REJECT

• Simple, Invariant Objects: Creating factories for simple POJOs, DTOs, or domain entities with standard constructors is over-engineering.
• IoC/DI Framework Usage: Modern frameworks (e.g., Spring, NestJS, Wire) act as global IoC containers. Writing custom Abstract Factories for singleton services managed by DI containers is redundant.

---

2. Strategy Pattern

Core Concept

The Strategy Pattern decouples algorithm selection from algorithm execution. Instead of embedding complex conditional engines into core business logic, it encapsulates each algorithmic variation behind a common interface.

Scenario: Multi-Gateway Payment Router

A payment routing system needs to process transactions through different payment providers (Stripe, PayPal, Adyen) based on user context or region.

❌ Violated Architecture: Conditional Monolith

public class PaymentProcessor {

    public PaymentResult processPayment(String gateway, BigDecimal amount, PaymentInfo info) {
        if ("STRIPE".equalsIgnoreCase(gateway)) {
            // 50 lines of Stripe SDK calls, header setup, and signature generation
            System.out.println("Processing via Stripe SDK...");
            return new PaymentResult(true, "ch_stripe_123");
        } else if ("PAYPAL".equalsIgnoreCase(gateway)) {
            // 60 lines of PayPal OAuth token fetching & payload mapping
            System.out.println("Processing via PayPal REST API...");
            return new PaymentResult(true, "pay_paypal_456");
        } else if ("ADYEN".equalsIgnoreCase(gateway)) {
            // 40 lines of Adyen HMAC signature generation & request building
            System.out.println("Processing via Adyen API...");
            return new PaymentResult(true, "adyen_tx_789");
        } else {
            throw new IllegalArgumentException("Unsupported payment gateway: " + gateway);
        }
    }
}

Enter fullscreen mode Exit fullscreen mode

---

✅ Refactored Architecture: Encapsulated Strategy Registry

graph LR
    Client[PaymentService] --> Registry[PaymentRegistry]
    Registry --> StrategyInterface[PaymentStrategy Interface]
    StrategyInterface <|.. Stripe[StripeStrategy]
    StrategyInterface <|.. PayPal[PayPalStrategy]
    StrategyInterface <|.. Adyen[AdyenStrategy]

Enter fullscreen mode Exit fullscreen mode

Code Implementation

// 1. Common Strategy Interface
public interface PaymentStrategy {
    void pay(double amount);
}

// 2. Concrete Strategy A
public class StripeStrategy implements PaymentStrategy {
    @Override
    public void pay(double amount) {
        // Logic specific to Stripe API
        System.out.println("Paid $" + amount + " using Stripe.");
    }
}

// Concrete Strategy B
public class PayPalStrategy implements PaymentStrategy {
    @Override
    public void pay(double amount) {
        // Logic specific to PayPal API
        System.out.println("Paid $" + amount + " using PayPal.");
    }
}

// 3. Simple Strategy Registry
public class PaymentRegistry {
    private final Map<String, PaymentStrategy> strategies = new HashMap<>();

    public PaymentRegistry() {
        // Register strategies by key
        strategies.put("STRIPE", new StripeStrategy());
        strategies.put("PAYPAL", new PayPalStrategy());
    }

    public PaymentStrategy get(String type) {
        PaymentStrategy strategy = strategies.get(type.toUpperCase());
        if (strategy == null) {
            throw new IllegalArgumentException("Invalid payment type: " + type);
        }
        return strategy;
    }
}

// 4. Client Code
public class PaymentService {
    private final PaymentRegistry registry = new PaymentRegistry();

    public void processPayment(String gatewayType, double amount) {
        // Fetch the matching strategy and execute it
        PaymentStrategy strategy = registry.get(gatewayType);
        strategy.pay(amount);
    }

    public static void main(String[] args) {
        PaymentService service = new PaymentService();
        service.processPayment("STRIPE", 100.0); // Output: Paid $100.0 using Stripe.
        service.processPayment("PAYPAL", 50.0);   // Output: Paid $50.0 using PayPal.
    }
}

Enter fullscreen mode Exit fullscreen mode

Why Do We Need It?

• Eliminates Control Flow Bloat: Replaces complex if-else or switch blocks with lookup mechanisms.
• Isolated Testing: Individual algorithms can be unit-tested in isolation without instantiating surrounding services.
• Open/Closed Compliance: Adding a new integration (e.g., NetBankingStrategy) only requires adding a class and registering it.

Architectural Trade-offs

• Class/Module Explosion: Trades a single multi-branching file for multiple individual concrete strategy classes, a registry, and an interface contract.

When to AVOID or REJECT

• Invariant/Trivial Logic: If variations are simple and change rarely, standard conditional statements are sufficient.
• Functional Programming Paradigms: In languages with first-class functions (e.g., TypeScript, Rust, Go, modern Java), creating heavy class hierarchies for strategies is an anti-pattern. Passing lambdas or higher-order functions is preferred.

---

3. Adapter Pattern

Core Concept

The Adapter Pattern functions as a structural translator between incompatible interfaces. It allows core domain contracts to remain clean while translating requests to and from third-party APIs or legacy systems.

Scenario: KYC Verification Integration

An onboarding service requires third-party Know-Your-Customer (KYC) identity verification, using an legacy external vendor SDK (LegacyPersonaSdk).

❌ Violated Architecture: Domain Polluted by External Contracts

// Legacy vendor class (Unmodifiable external SDK)
class LegacyPersonaSdk {
    public int executeCheck(String passportNum, String countryIso2) {
        // Returns 200 for pass, 401 for fail, 500 for error
        System.out.println("Calling Legacy Persona API...");
        return 200;
    }
}

// Violated Business Logic directly polluted with vendor-specific parameters and status codes
public class OnboardingService {
    private final LegacyPersonaSdk legacySdk = new LegacyPersonaSdk();

    public boolean verifyUser(String passportNumber, String countryCode) {
        // Direct coupling to legacy method signature and vendor status codes
        int responseCode = legacySdk.executeCheck(passportNumber, countryCode);
        return responseCode == 200;
    }
}

Enter fullscreen mode Exit fullscreen mode

---

✅ Refactored Architecture: Domain Adapter Isolation

graph LR
    Client[OnboardingService] --> TargetInterface[KycVerifier Interface]
    Adapter[LegacyPersonaAdapter] ..|> TargetInterface
    Adapter --> Adaptee[LegacyPersonaSdk]

Enter fullscreen mode Exit fullscreen mode

Code Implementation

// 1. Clean Application Target Contract
public interface KycVerifier {
    KycResult verifyUser(UserIdentity identity);
}

// Domain Models
record UserIdentity(String passportNumber, String countryCode) {}
record KycResult(boolean status, String referenceId) {}

// 2. Unmodifiable External API / Adaptee
class LegacyPersonaSdk {
    public int executeCheck(String passportNum, String countryIso2) {
        System.out.println("Calling Legacy Persona API...");
        return 200;
    }
}

// 3. Concrete Adapter Implementing Target Contract
public class LegacyPersonaAdapter implements KycVerifier {
    private final LegacyPersonaSdk legacySdk;

    public LegacyPersonaAdapter(LegacyPersonaSdk legacySdk) {
        this.legacySdk = legacySdk;
    }

    @Override
    public KycResult verifyUser(UserIdentity identity) {
        // Translate domain model to legacy SDK parameters
        int rawStatusCode = legacySdk.executeCheck(identity.passportNumber(), identity.countryCode());

        // Translate legacy response codes into clean domain response objects
        boolean passed = (rawStatusCode == 200);
        return new KycResult(passed, "PERSONA-TX-" + System.currentTimeMillis());
    }
}

// 4. Clean Business Logic (Completely decoupled from legacy vendor code)
public class OnboardingService {
    private final KycVerifier kycVerifier;

    // Injected via Interface
    public OnboardingService(KycVerifier kycVerifier) {
        this.kycVerifier = kycVerifier;
    }

    public boolean onboardUser(UserIdentity identity) {
        KycResult result = kycVerifier.verifyUser(identity);
        return result.status();
    }
}

Enter fullscreen mode Exit fullscreen mode

Why Do We Need It?

• Vendor Agnosticism: Prevents internal domain contracts from being dictated by external vendor models.
• Resilience to Change: Swapping out a vendor only requires writing a new adapter implementation; core business code remains untouched.

Architectural Trade-offs

• Data Mapping Overhead: Translating internal models to vendor-specific parameters adds minor CPU and memory overhead during object mapping.
• Leaky Abstractions: If target legacy systems lack key capabilities, adapters may need to perform workarounds or hide missing functionality.

When to AVOID or REJECT

• Direct 1:1 Mirror Interfaces: Creating an adapter that simply passes parameters through without signature or format changes adds unnecessary boilerplate.
• Internal Code Ownership: If you own and control both caller and recipient source code, refactor the target API directly rather than wrapping it in an adapter.

---

4. Observer Pattern

Core Concept

The Observer Pattern defines a one-to-many publish-subscribe dependency. When a core Subject undergoes a state change, it broadcasts event notifications to registered Observers without knowing their concrete details or execution mechanics.

Scenario: Order Checkout Side-Effects

When an order is placed in an e-commerce application, downstream actions must be executed: sending a customer email notification and updating warehouse inventory.

❌ Violated Architecture: Hardcoded Side-Effects

public class OrderService {
    private final EmailService emailService = new EmailService();
    private final InventoryService inventoryService = new InventoryService();

    public void placeOrder(String orderId, String customerId, double amount) {
        // Core Business Transaction
        System.out.println("Order " + orderId + " saved to DB.");

        // BAD DESIGN: Core service explicitly knows and synchronously calls downstream tasks
        emailService.sendConfirmationEmail(customerId, orderId);
        inventoryService.deductStock(orderId);
    }
}

Enter fullscreen mode Exit fullscreen mode

---

✅ Refactored Architecture: Decoupled Publisher-Subscriber System

graph TD
    OrderService[OrderService] --> Publisher[OrderPublisher]
    Publisher --> ListenerInterface[OrderEventListener]
    ListenerInterface <|.. EmailListener[EmailNotificationListener]
    ListenerInterface <|.. InventoryListener[InventoryUpdateListener]

Enter fullscreen mode Exit fullscreen mode

Code Implementation

// 1. Immutable Event Payload
public record OrderPlacedEvent(String orderId, String customerId, double amount) {}

// 2. Observer (Subscriber) Interface
public interface OrderEventListener {
    void onOrderPlaced(OrderPlacedEvent event);
}

// 3. Concrete Observers (Decoupled Side-Effects)
public class EmailNotificationListener implements OrderEventListener {
    @Override
    public void onOrderPlaced(OrderPlacedEvent event) {
        System.out.println("Sending email to customer " + event.customerId() + " for order " + event.orderId());
    }
}

public class InventoryUpdateListener implements OrderEventListener {
    @Override
    public void onOrderPlaced(OrderPlacedEvent event) {
        System.out.println("Deducting inventory stock for order " + event.orderId());
    }
}

// 4. Subject / Publisher (Manages Subscribers & Broadcasts Events)
public class OrderPublisher {
    private final List<OrderEventListener> listeners = new ArrayList<>();

    public void registerListener(OrderEventListener listener) {
        listeners.add(listener);
    }

    public void publishOrderPlaced(OrderPlacedEvent event) {
        for (OrderEventListener listener : listeners) {
            try {
                listener.onOrderPlaced(event);
            } catch (Exception e) {
                // Isolate subscriber failures so they don't break other listeners
                System.err.println("Subscriber failed: " + e.getMessage());
            }
        }
    }
}

// 5. Clean Core Business Logic
public class OrderService {
    private final OrderPublisher publisher;

    public OrderService(OrderPublisher publisher) {
        this.publisher = publisher;
    }

    public void placeOrder(String orderId, String customerId, double amount) {
        // Core Business Logic
        System.out.println("Order " + orderId + " saved to DB.");

        // Clean event broadcast: OrderService has NO direct dependency on Email or Inventory services
        publisher.publishOrderPlaced(new OrderPlacedEvent(orderId, customerId, amount));
    }
}

Enter fullscreen mode Exit fullscreen mode

Why Do We Need It?

• It removes tight coupling among components.
• Every listener can be built and tested separately and failures of each listeners can be handled separately so that addition of any new listener doesn’t break existing flows.
• It helps to follow single responsibility principle, open closed principle, dependency inversion principle

Architectural Trade-offs

• Hidden Execution Chains & Debugging Complexity: Because subscribers are registered dynamically, tracing control flow through log files becomes difficult. You can no longer simply "Go to Definition" in your IDE to see everything that happens after a state change.

When to AVOID or REJECT

• If a process has exactly one permanent side effect that will never change, adding an observer registry introduces unnecessary indirection.

Scaling Up: From In-Memory Observers to Distributed Architecture

In microservices architectures, in-memory observers evolve into Distributed Event-Driven Architecture (EDA). Instead of using in-memory registries, services publish messages to distributed brokers like Apache Kafka, AWS SNS/SQS, or RabbitMQ.

To preserve system consistency without losing events, production architectures often pair this with the Transactional Outbox Pattern:

1. Business data and event records are written to the database within a single database transaction.
2. A separate relay process reads outbox entries and publishes them to the message broker.

graph LR
    subgraph Microservice Context
        Service[Order Service] --> DB[(Database / Outbox Table)]
    end
    DB --> Relay[Debezium / Outbox Publisher]
    Relay --> Broker[Apache Kafka / RabbitMQ]
    Broker --> Listener1[Notification Service]
    Broker --> Listener2[Inventory Service]

Enter fullscreen mode Exit fullscreen mode

---

5. Decorator Pattern

Core Concept

The Decorator Pattern allows responsibilities to be added to an object dynamically at runtime without modifying its core code or introducing static subclass explosion. It wraps the core component with layers that add cross-cutting behavior.

Scenario: Credit Card Processing Optional Add-ons

A credit card processing service can be augmented with optional runtime add-ons, such as fraud checking and audit logging.

❌ Violated Architecture: Subclass Permutation Chaos

Creating subclasses for every combination of optional behavior causes an exponential growth of classes.

graph TD
    A[PaymentProcessor Base] --> B[FraudCheckingPaymentProcessor]
    A --> C[AuditLoggingPaymentProcessor]
    A --> D[MetricsPaymentProcessor]
    B --> E[Fraud + Logging PaymentProcessor]
    C --> E
    C --> F[Logging + Metrics PaymentProcessor]
    D --> F
    B --> G[Fraud + Metrics PaymentProcessor]
    D --> G
    E --> H[Fraud + Logging + Metrics PaymentProcessor]
    F --> H
    G --> H

Enter fullscreen mode Exit fullscreen mode

public class BasicPaymentProcessor {
    public void processPayment(double amount) {
        System.out.println("Processing credit card payment of $" + amount);
    }
}

// Subclass permutations needed for every combination!
public class LoggingPaymentProcessor extends BasicPaymentProcessor { /* ... */ }
public class FraudCheckingPaymentProcessor extends BasicPaymentProcessor { /* ... */ }
public class LoggingAndFraudCheckingPaymentProcessor extends BasicPaymentProcessor { /* ... */ }
// Adding 3 more features leads to subclass explosion!

Enter fullscreen mode Exit fullscreen mode

---

✅ Refactored Architecture: Dynamic Composition Chain

graph LR
    Client[Client Code] --> FraudDecorator[FraudCheckDecorator]
    FraudDecorator --> AuditDecorator[AuditLoggingDecorator]
    AuditDecorator --> Core[StandardPaymentProcessor]

Enter fullscreen mode Exit fullscreen mode

Code Implementation

// 1. Component Interface
public interface PaymentProcessor {
    void processPayment(double amount);
}

// 2. Concrete Base Component (Core Domain Logic)
public class StandardPaymentProcessor implements PaymentProcessor {
    @Override
    public void processPayment(double amount) {
        System.out.println("Executing core payment debit of $" + amount);
    }
}

// 3. Abstract Decorator (Maintains reference to wrapped component)
public abstract class PaymentProcessorDecorator implements PaymentProcessor {
    protected final PaymentProcessor wrappedProcessor;

    public PaymentProcessorDecorator(PaymentProcessor wrappedProcessor) {
        this.wrappedProcessor = wrappedProcessor;
    }

    @Override
    public void processPayment(double amount) {
        wrappedProcessor.processPayment(amount); // Default delegation
    }
}

// 4. Concrete Decorator A
public class FraudCheckDecorator extends PaymentProcessorDecorator {
    public FraudCheckDecorator(PaymentProcessor wrappedProcessor) {
        super(wrappedProcessor);
    }

    @Override
    public void processPayment(double amount) {
        System.out.println("[FRAUD CHECK] Validating risk score for amount: $" + amount);
        super.processPayment(amount); // Delegate to next layer
    }
}

// Concrete Decorator B
public class AuditLoggingDecorator extends PaymentProcessorDecorator {
    public AuditLoggingDecorator(PaymentProcessor wrappedProcessor) {
        super(wrappedProcessor);
    }

    @Override
    public void processPayment(double amount) {
        System.out.println("[AUDIT LOG] Payment initiated at " + System.currentTimeMillis());
        super.processPayment(amount); // Delegate to next layer
        System.out.println("[AUDIT LOG] Payment execution finished.");
    }
}

// 5. Usage / Pipeline Construction
public class PaymentApplication {
    public static void main(String[] args) {
        // Base Processor
        PaymentProcessor processor = new StandardPaymentProcessor();

        // Dynamically compose processing pipeline at runtime: Fraud Check -> Audit Log -> Core Payment
        PaymentProcessor securePipeline = new FraudCheckDecorator(
            new AuditLoggingDecorator(processor)
        );

        securePipeline.processPayment(250.00);
    }
}

Enter fullscreen mode Exit fullscreen mode

Why Do We Need It?

• Prevents Class Explosion: Replaces static inheritance combinations with dynamic composition.
• Single Responsibility Principle: Cross-cutting concerns (logging, fraud checks, metrics) are separated into individual wrapper classes.

Architectural Trade-offs

• Identity Crisis: A decorated instance does not share object identity with the inner wrapped component (decoratedObject != innerObject). Equality checks (==) or reflection-based logic can break.
• Ordering Overhead: If decorators depend on a specific execution order, nested composition can introduce subtle runtime bugs.

When to AVOID or REJECT

• Strict Order Dependencies: If Decorator A must always execute before Decorator B and out-of-order execution breaks system state, wrapper pipelines add risk.
• Framework Interceptors Available: Modern enterprise frameworks provide Aspect-Oriented Programming (AOP) or Middleware/Filter pipelines (e.g., Spring AOP, Express Middlewares, gRPC Interceptors) which handle cross-cutting concerns cleanly without manually instantiating object wrappers.

---

💡 Get the Full 10-Page System Design Guide

Subscribe to The Tech Builder Newsletter to instantly get the full, unredacted guide for free.

Every week, subscribers receive:

• 🎯 Deep-dive production postmortems & system design trade-off analysis.
• 🛠️ Real-world architecture playbooks for Senior ICs, Tech Leads, and Architects.
• 🎁 Instant Bonus: Get the Full 6-Month Prep Tracker & Study Schedule + 10-Page System Design Cheat Sheet immediately upon subscribing.

👉 Get the Full System Design Cheat Sheet