In this chapter, you'll learn how to clean up your e-commerce store's code by applying key 'Gang of Four' Design Patterns. You'll use the Strategy Pattern to create adaptable shipping rules, the Builder Pattern to manage complex order creation, and the Observer Pattern to streamline the checkout process. Additionally, you'll gain insight into when design patterns can lead to unnecessary complexity, helping you make informed architectural decisions.

Why the Store's Architecture is Tangling

EASY

In the beginning, our e-commerce store's order process was straightforward: charge the customer's card and store the order in the database. But as the store evolved, so did the complexity of placing an order. Now, it involves assigning loyalty points, calculating multiple shipping options, sending a receipt email, and updating a legacy warehouse system.

The `OrderService` class has become a monolithic block of over 2,000 lines, filled with numerous `if-else` statements like `if (shippingType.equals("EXPRESS"))`. This makes the code difficult to maintain and test. Developers are often hesitant to make changes, fearing that modifying one part could inadvertently break another, such as the payment logic when altering the email system.

Design patterns come to the rescue by offering proven solutions to these architectural challenges. They help us organize code better by separating different responsibilities, allowing us to switch behaviors easily and decouple components.

By using design patterns, we can avoid 'God Classes' that try to do everything. Instead, we create smaller, more manageable classes that handle specific tasks, making the system easier to understand and modify.

The ultimate aim is decoupling: enabling different parts of the system to evolve independently without causing disruptions elsewhere. This not only improves code quality but also boosts developer confidence when making changes.

Avoid 'God Classes' by breaking down responsibilities into smaller, focused classes.
Long if-else chains make code hard to maintain and test; design patterns can simplify this.
Design patterns offer a common language for solving complex architectural issues.
Decoupling allows parts of the system to change without affecting others.
Using design patterns can increase code readability and maintainability.


// Consider using a design pattern to replace this:
switch (type) {
    case "STANDARD":
        // handle standard shipping
        break;
    case "EXPRESS":
        // handle express shipping
        break;
    case "OVERNIGHT":
        // handle overnight shipping
        break;
}

Strategy Pattern: Managing Different Shipping Options

EASY

Imagine you're running an online store with multiple shipping options: Standard, Express, and Overnight. If you hardcode these options using a big switch statement in your `CheckoutService`, you're setting yourself up for trouble. This approach breaks the Open/Closed Principle, which states that code should be open for extension but closed for modification. Every time a new shipping method is added, you have to dive back into the core logic and make changes.

The Strategy Pattern offers a cleaner solution. Instead of embedding all shipping calculations directly into your service, you can separate each shipping algorithm into its own class. These classes implement a common `ShippingStrategy` interface. Now, the `CheckoutService` doesn't need to know the details of how each shipping cost is calculated. It just holds a reference to a `ShippingStrategy` and calls its `.calculate(cart)` method.

At runtime, the appropriate shipping strategy is injected based on the user's selection. This makes your codebase more flexible and easier to maintain. If a new shipping option is introduced, you simply create a new class that implements `ShippingStrategy`. No need to alter existing code.

With modern Java, you can make this even more elegant. Simple strategies can be defined using Lambda expressions, reducing boilerplate and making your code more readable. This is especially useful for straightforward calculations that don't require a full class implementation.

The Strategy Pattern separates different algorithms into their own classes, promoting cleaner code.
It removes the need for large conditional statements by dynamically assigning behaviors.
Core services interact with a generic interface, unaware of specific algorithm details.
Adding a new shipping method requires only a new class, leaving existing code untouched.
Modern Java supports concise Lambda expressions for simple strategy implementations.


public interface ShippingStrategy {
    BigDecimal calculate(Cart cart);
}

// CheckoutService is decoupled from specific shipping calculations
public class CheckoutService {
    public Receipt checkout(Cart cart, ShippingStrategy shipping) {
        BigDecimal cost = shipping.calculate(cart);
        return new Receipt(cart.items(), cost);
    }
}

Builder Pattern: Crafting Complex Orders

EASY

Imagine you're running an online store, and your `Order` object has grown to include a user ID, shipping address, billing details, a discount code, a gift message, and tax flags. Using a constructor like `new Order(1, add1, add2, null, true, "Happy B-Day")` is not only cumbersome but also prone to errors. This is known as the 'Telescoping Constructor Anti-pattern'.

The Builder Pattern offers a solution by providing a fluent, step-by-step approach to object creation. Instead of cramming multiple parameters into a single constructor, you chain methods that clearly describe each step: `.withAddress(add1).isGift(true).build()`. This approach improves readability and reduces errors.

In Java, the Builder Pattern is widely adopted for constructing complex objects, such as `HttpRequest` objects, and for creating immutable domain objects that require validation before instantiation. This pattern is especially useful when an object has optional parameters or when the order of parameters is not intuitive.

The Builder Pattern not only enhances code readability but also ensures that objects are constructed in a valid state. Validation logic can be encapsulated within the `.build()` method, preventing the creation of illegal states.

By using the Builder Pattern, you gain the flexibility to construct objects in a more controlled and descriptive manner, making your codebase easier to maintain and less error-prone.

Avoids the error-prone 'Telescoping Constructor Anti-pattern' by using a fluent API.
Enhances readability and maintainability with clear, descriptive method chaining.
Supports the creation of immutable objects with optional parameters.
Encapsulates validation logic within the `.build()` method to prevent illegal states.
Widely used in Java for constructing complex objects like `HttpRequest`.


Order currentOrder = Order.builder()
    .userId(998)
    .shippingAddress(userProfile.address())
    .applyDiscountCode("SUMMER24")
    .isGift(true)
    .build();

Observer Pattern: Streamlining the Checkout Process

MID

Imagine when a customer completes a purchase, three tasks need to happen simultaneously: notifying the warehouse, sending a receipt to the customer, and updating their loyalty points. If our `CheckoutService` directly handles each of these tasks, it becomes a tightly coupled, inflexible system.

This is where the **Observer Pattern** comes into play. Instead of directly managing each task, `CheckoutService` acts as a broadcaster. Upon payment success, it announces: 'Order 123 was paid!'.

Observers like `EmailNotifier`, `InventoryManager`, and `LoyaltyService` are designed to listen for this announcement. Each observer independently responds to the event, executing its specific task without the `CheckoutService` needing to know about them.

This architecture allows for a loosely coupled system, where adding or modifying tasks doesn't require changes to the `CheckoutService`. It enhances maintainability and scalability, as new observers can be added without altering existing code.

In modern Java applications, especially those using Spring Boot, the Observer Pattern is often implemented using events. The framework provides tools like `ApplicationEventPublisher` and `@EventListener` to facilitate this pattern efficiently.

Decouples the event Producer from Consumers, enhancing flexibility.
Producers emit a typed Event object, such as `OrderPlacedEvent`.
Consumers listen for specific Events and execute their logic independently.
Spring Boot simplifies this pattern with `ApplicationEventPublisher` and `@EventListener`.
Eases system maintenance by allowing new observers without altering the producer.


@Service
public class LoyaltyService {
    @EventListener
    public void handleOrderEvent(OrderPlacedEvent event) {
        // Automatically reacts to the event without direct coupling to CheckoutService
        addPoints(event.userId(), event.totalSpent());
    }
}

Decorator Pattern: Layering Price Adjustments

MID

When pricing a product, consider various adjustments. Start with a base cost of $100. On holidays, apply a 10% discount. VIP customers receive an additional $5 off. Shipping to Canada incurs a $15 tariff. Creating a subclass for every combination like `HolidayVipCanadianProduct` quickly becomes unmanageable.

The **Decorator Pattern** offers a solution by allowing you to add behaviors to objects dynamically, without modifying their code. You begin with a `PriceCalculator` as your base. Then, wrap it with a `HolidayDiscountDecorator` and further wrap it with a `TariffDecorator`. Each decorator adds its own logic, layering behaviors like an onion.

This pattern is especially useful when you need to extend functionality without creating a complex hierarchy of subclasses. In Java, this approach is used extensively in the I/O system, such as wrapping a `FileInputStream` with a `BufferedInputStream` to enhance its capabilities.

Using decorators, you can dynamically adjust the price based on different criteria, maintaining a clean and flexible code structure. This approach is not only efficient but also aligns well with the Open/Closed Principle of object-oriented design, where classes should be open for extension but closed for modification.

The Decorator Pattern dynamically adds responsibilities to an object without altering its structure.
It provides a flexible alternative to subclassing for extending functionality.
Decorators follow the same interface as the objects they wrap, ensuring compatibility.
Behaviors are layered sequentially, allowing each decorator to enhance or modify the result.
This pattern supports the Open/Closed Principle, promoting code that is easy to extend and maintain.


Price base = new BasePrice(100.00);
// Sequentially wrap the base price to modify behavior
Price finalPrice = new TariffDecorator(
                       new HolidayDiscountDecorator(
                           new VipDiscountDecorator(base)
                       )
                   );

System.out.println(finalPrice.calculate());

Factory Method: Crafting Payment Processors

MID

In our store application, users can pay using Credit Card, PayPal, or Crypto. Each payment method requires a unique external API client. If you directly instantiate these clients like `new PayPalClient()`, your code becomes tightly coupled to specific APIs, making it hard to maintain and extend.

The **Factory Method Pattern** offers a solution by centralizing the creation logic. Instead of scattering object creation throughout your code, you delegate it to a `PaymentProcessorFactory`. This factory takes a string input, such as "PayPal", and returns a `PaymentProcessor` interface. Internally, it handles the complexity of choosing and setting up the right client.

By using the Factory Method, your application code remains clean and focused. You simply request a processor from the factory, and it abstracts away the details of which concrete class is used. This approach enhances maintainability and makes it easier to add new payment methods in the future.

Moreover, this pattern exemplifies the principle of programming to an interface, not an implementation. Your code interacts with the `PaymentProcessor` interface, allowing for flexibility and easier testing.

In real-world applications, frameworks like Spring often act as large-scale factories, managing object creation and dependencies, which illustrates the power of this pattern in a broader context.

The Factory Method Pattern centralizes object creation, reducing code duplication.
It decouples your application from specific implementations, enhancing maintainability.
Clients receive a generic interface, promoting flexibility and easier testing.
Facilitates adding new payment methods without altering existing code.
Frameworks like Spring leverage this pattern for dependency management.


public class PaymentProcessorFactory {
    public static PaymentProcessor getProcessor(String method) {
        return switch (method.toUpperCase()) {
            case "PAYPAL" -> new PayPalClient(System.getenv("PAYPAL_KEY"));
            case "CREDIT" -> new StripeClient();
            case "CRYPTO" -> new CryptoClient();
            default -> throw new IllegalArgumentException("Unsupported payment method: " + method);
        };
    }
}

Proxy Pattern: Efficient User Profile Loading

ADVANCED

Imagine a user logs into an online store. Fetching their email and name is quick and easy. But pulling their entire order history of 500 past purchases from the database? That's a different story—it can be painfully slow. If we retrieve this data every time they log in, even if they don't check their order history, our database might struggle under the load.

This is where the **Proxy Pattern** comes in handy. It allows us to create a `UserProxy` object that mimics a real `User` object. This proxy contains the basic, fast-to-retrieve data like name and email. However, the `orderHistory` list is initially empty.

The magic happens when the application needs the order history. The first time `proxy.getOrderHistory()` is called, the proxy springs into action. It pauses the current thread, fetches the order history with a heavy SQL query, and then returns the data. The rest of the application remains blissfully unaware that it was dealing with a proxy.

In real-world applications, frameworks like Spring use proxies extensively. For instance, they manage lazy-loaded database relationships and handle `@Transactional` boundaries efficiently.

Understanding the Proxy Pattern not only helps in designing efficient systems but also prepares you for questions about lazy loading and design patterns in technical interviews.

A Proxy serves as a placeholder for another object, deferring heavy operations until necessary.
Lazy Initialization Proxies delay expensive operations like database calls until the data is actually needed.
A Proxy implements the same interface as the real object, making it transparent to the client code.
Spring AOP uses dynamic proxies to seamlessly add features like logging, security, and transaction management.


public class LazyOrderProxy implements OrderRepository {
    private RealOrderRepository realRepo;
    
    public List<Order> getOrders(long userId) {
        if (realRepo == null) {
            realRepo = new RealOrderRepository(); // Initialization is deferred until needed
        }
        return realRepo.getOrders(userId);
    }
}

Adapter Pattern: Bridging the Legacy Inventory System

ADVANCED

Imagine your e-commerce platform is a sleek, modern machine, communicating effortlessly through JSON and REST APIs. But now, you've acquired a legacy warehouse system that only speaks in XML and communicates via FTP. Rewriting your `InventoryService` to accommodate this outdated system isn't an option. This is where the **Adapter Pattern** shines.

The Adapter Pattern acts like a translator, allowing two incompatible systems to communicate without altering their core structures. By implementing an adapter, you can bridge the gap between your modern application and the legacy system.

Let's create an `XmlFtpAdapter` class that implements your existing `InventoryService` interface. This adapter will handle the messy details: converting JSON requests to XML, communicating over FTP, and translating the responses back into JSON.

When your application calls `adapter.checkStock(productId)`, the adapter translates this call into XML, sends it over FTP, and processes the XML response. This keeps your domain logic clean and focused on modern standards.

The Adapter Pattern is like using a power adapter to plug an American device into a European outlet. It allows you to maintain compatibility without redesigning your entire system.

The Adapter Pattern enables communication between incompatible interfaces without modifying them.
It isolates legacy or third-party code from your clean domain models.
Your application interacts with a clean interface, while the adapter handles the complexity.
Think of it as a power adapter for different plug standards.
Adapting legacy systems can extend their usefulness without a complete overhaul.


public class XmlFtpAdapter implements InventoryService {
    private final LegacyXmlSystem legacySystem = new LegacyXmlSystem();

    @Override
    public boolean isAvailable(String productId) {
        // Convert JSON request to XML format
        String xmlRequest = "<item>" + productId + "</item>";
        // Send XML over FTP and receive a response
        String xmlResponse = legacySystem.sendFtpRequest(xmlRequest);
        // Process the XML response
        return xmlResponse.contains("SUCCESS");
    }
}

Avoiding Pattern Overuse: Recognizing Design Smells

ADVANCED

Design patterns are invaluable in creating scalable and maintainable software architectures. However, misusing them is a frequent pitfall, especially among intermediate developers. This misuse is humorously dubbed 'AbstractSingletonProxyFactoryBean' syndrome in the Java community.

Consider the Strategy Pattern: it's meant for scenarios where logic may vary. If your logic is static, using this pattern is unnecessary complexity. Similarly, an Abstract Factory for simple object creation, like a String, is overkill. Such over-engineering turns your codebase into a maze of abstractions, daunting for new team members and inefficient for solving problems that don't exist.

The principle of YAGNI—'You Aren't Gonna Need It'—is crucial here. Begin with straightforward, readable code. Only introduce a design pattern when you encounter a genuine problem that it can solve. Patterns should simplify your code, not complicate it.

Remember, the best engineers prioritize clarity and simplicity. They reserve patterns for when they are truly needed, allowing the code to evolve naturally as requirements change.

Overuse of patterns leads to unnecessary complexity in simple scenarios.
Each abstraction layer adds complexity, making the system harder to understand.
YAGNI advises against building complex architectures for hypothetical future needs.
Start with simple solutions; evolve to patterns only when a clear need arises.
Patterns should reduce complexity, not showcase cleverness.


// Avoid unnecessary complexity with simple solutions:
System.out.println("Hello World");

Chapter takeaway

Design patterns offer a common language that helps engineers communicate effectively. By identifying and addressing code structure issues, you can apply these patterns to simplify logic, enhance testability, and maintain a scalable application.