Skip to main content
Back to Library
pragmatic clean code minimizing cognitive load in production java

Architecting for Change

4 min read Chapter 23 of 25
Summary

Effective component boundaries balance high cohesion and low...

Effective component boundaries balance high cohesion and low coupling. Techniques like SLAP, guard clauses, ADTs, and Test Builders enforce these principles, enabling modular, readable, and maintainable systems. A refactored payment processor demonstrates these concepts, using Java 21's sealed interfaces and pattern matching for explicit error handling and adaptability.

Architecting for Change

Designing component boundaries is crucial for software systems that need to evolve over time. A good component boundary should have high cohesion, low coupling, and an intent-revealing interface. In this section, we will explore how techniques such as the Single Level of Abstraction Principle (SLAP), guard clauses, Algebraic Data Types (ADTs), and Test Builders can help create and enforce well-bounded components.

The Importance of Component Boundaries

Component boundaries are the interfaces through which different parts of a system interact. A well-designed boundary should make it easy to modify or replace one component without affecting others. This is achieved by minimizing coupling, which refers to the degree of interdependence between components. High coupling makes it difficult to change one component without breaking others, leading to a rigid and fragile system.

Techniques for Improving Component Boundaries

Single Level of Abstraction Principle (SLAP)

The SLAP principle states that a component should operate at a single level of abstraction. This means that a component should either be concerned with high-level business logic or low-level implementation details, but not both. By separating these concerns, we can reduce cognitive load and make the system easier to understand and modify.

Guard Clauses

Guard clauses are preconditions that check the validity of input parameters at the beginning of a function. They help prevent deep nesting and make the code more readable. By using guard clauses, we can ensure that a component is always in a valid state and reduce the likelihood of errors.

Algebraic Data Types (ADTs)

ADTs are a way of defining data structures that consist of sum types (sealed interfaces) and product types (records). They enable exhaustive compiler analysis and make it easier to reason about the code. By using ADTs, we can create components that are more modular and easier to compose.

Test Builders

Test Builders are a pattern for improving the readability of unit tests. They provide a way to create test data in a fluent and expressive manner, making it easier to write and maintain tests. By using Test Builders, we can reduce the noise in our tests and make them more focused on the behavior being tested.

Example: Refactoring a Poorly Bounded Component

Let’s consider an example of a poorly bounded component that can be improved using the techniques mentioned above. Suppose we have a PaymentProcessor component that is responsible for processing payments. The component has a complex interface with many methods, each of which performs a different type of payment processing.

public class PaymentProcessor {
    public void processPayment(Payment payment) {
        if (payment.getType() == PaymentType.CREDIT_CARD) {
            // process credit card payment
        } else if (payment.getType() == PaymentType.PAYPAL) {
            // process paypal payment
        } else {
            // handle unknown payment type
        }
    }
}

This component has high coupling and low cohesion. It is difficult to modify or replace without affecting other parts of the system. We can improve this component by applying the techniques mentioned above.

public sealed interface PaymentResult permits Success, Failure {
    record Success(String transactionId, long amount) implements PaymentResult {}
    record Failure(String reason, int errorCode) implements PaymentResult {}
}

public class PaymentProcessor {
    public PaymentResult processPayment(Payment payment) {
        return switch (payment.getType()) {
            case CREDIT_CARD -> processCreditCardPayment(payment);
            case PAYPAL -> processPaypalPayment(payment);
            default -> Failure("Unknown payment type", 400);
        };
    }

    private PaymentResult processCreditCardPayment(Payment payment) {
        // process credit card payment
    }

    private PaymentResult processPaypalPayment(Payment payment) {
        // process paypal payment
    }
}

In this refactored version, we have applied the SLAP principle by separating the concerns of payment processing into different methods. We have also used guard clauses to check the validity of the payment type and ADTs to define the PaymentResult interface. Finally, we can use Test Builders to improve the readability of our unit tests.

public class PaymentProcessorTest {
    @Test
    public void testProcessPayment() {
        Payment payment = new PaymentBuilder().withType(PaymentType.CREDIT_CARD).build();
        PaymentResult result = paymentProcessor.processPayment(payment);
        assertEquals(PaymentResult.Success.class, result.getClass());
    }
}

By applying these techniques, we can create components that are more modular, easier to understand, and easier to modify. This leads to a more maintainable and adaptable system, which is essential for reducing the total cost of ownership (TCO) over time.

Conclusion

Designing component boundaries is a critical aspect of software architecture. By applying techniques such as SLAP, guard clauses, ADTs, and Test Builders, we can create components that are well-bounded, modular, and easy to maintain. This leads to a more adaptable and maintainable system, which is essential for reducing TCO and improving the overall quality of the software.

Sources

No external sources were used in this section.