Low Component Dependence Allows for Isolated Maintenance

A low level of dependence means that changes can be made in an isolated manner. This applies when most of a component’s code volume is either internal or outgoing. Isolated maintenance means less work, as coding changes do not have effects outside the functionality that you are modifying.

Low Component Dependence Separates Maintenance Responsibilities

If all components are independent from each other, it is easier to distribute responsibilities for maintenance among separate teams. This follows from the advantage of isolated modification. Isolation is in fact a prerequisite for efficient division of development work among team members or among different teams.

By contrast, if components are tightly intertwined with each other, one cannot isolate and separate maintenance responsibilities among teams, since the effects of modifications will spill over to other teams. Aside from that code being hard to test, the effects of modifications may also be unpredictable. So, dependencies may lead to inconsistencies, more time spent on communication between developers, and time wasted waiting for others to complete their modifications.

Abstract Factory Design Pattern

Component independence reflects the high-level architecture of a software system. However, this is not a book on software architecture. In this section, we discuss only one design pattern that we frequently see applied in practice to successfully limit the amount of interface code exposed by a component: the Abstract Factory design pattern. A system that is loosely coupled is characterized by relying more on contracts and less on implementation details.

Many more design patterns and software architecture styles can help in keeping your architecture components loosely coupled. An example is using a framework for dependency injection (which allows Inversion of Control). For elaboration on other patterns, we kindly direct you to the many great books on design patterns and software architecture (see, for example, “Related Books”).

The Abstract Factory design pattern hides (or encapsulates) the creation of specific “products” behind a generic “product factory” interface. In this context, products are typically entities for which more than one variant exists. Examples are audio format decoder/encoder algorithms or user interface widgets that have different themes for “look and feel.” In the following example, we use the Abstract Factory design patten to encapsulate the specifics of cloud hosting platforms behind a small factory interface.

Suppose our codebase contains a component, called PlatformServices, that implements the management of services from a cloud hosting platform. Two specific cloud hosting providers are supported by the PlatformServices component: Amazon AWS and Microsoft Azure (more could be added in the future).

To start/stop servers and reserve storage space, we have to implement the following interface for a cloud hosting platform:

public interface CloudServerFactory {
    CloudServer launchComputeServer();

    CloudServer launchDatabaseServer();

    CloudStorage createCloudStorage(long sizeGb);
}

Based on this interface, we create two specific factory classes for AWS and Azure:

public class AWSCloudServerFactory implements CloudServerFactory {
    public CloudServer launchComputeServer() {
        return new AWSComputeServer();
    }

    public CloudServer launchDatabaseServer() {
        return new AWSDatabaseServer();
    }

    public CloudStorage createCloudStorage(long sizeGb) {
        return new AWSCloudStorage(sizeGb);
    }
}

public class AzureCloudServerFactory implements CloudServerFactory {
    public CloudServer launchComputeServer() {
        return new AzureComputeServer();
    }

    public CloudServer launchDatabaseServer() {
        return new AzureDatabaseServer();
    }

    public CloudStorage createCloudStorage(long sizeGb) {
        return new AzureCloudStorage(sizeGb);
    }
}

Note that these factories make calls to specific AWS and Azure implementation classes (which in turn do specific AWS and Azure API calls), but return generic interface types for servers and storage.

Code outside the PlatformServices component can now use the concise interface module CloudServerFactory—for example, like this:

public class ApplicationLauncher {

    public static void main(String[] args) {
        CloudServerFactory factory;
        if (args[1].equals("-azure")) {
            factory = new AzureCloudServerFactory();
        } else {
            factory = new AWSCloudServerFactory();
        }
        CloudServer computeServer = factory.launchComputeServer();
        CloudServer databaseServer = factory.launchDatabaseServer();

The CloudServerFactory interface of the PlatformServices provides a small interface for other components in the codebase. This way, these other components can be loosely coupled to it.

Objection: Component Dependence Cannot Be Fixed Because the Components Are Entangled

“We cannot get component dependence right because of mutual dependencies between components.”

Entangled components are a problem that you experience most clearly during maintenance. You should start by analyzing the modules in the throughput category, as it has the most serious effect on the ease of testing and on predicting what exactly the functionality does.

When you achieve clearer boundaries for component responsibilities, it improves the analyzability and testability of the modules within. For example, modules with an extraordinary number of incoming calls may signal that they have multiple responsibilities and can be split up. When they are split up, the code becomes easier to analyze and test. For elaboration, please refer to Chapter 6.

Objection: No Time to Fix

“In the maintenance team, we understand the importance of achieving low component dependence, but we are not granted time to fix it.”

We understand how this is an issue. Development deadlines are real, and there may not be time for refactoring, or what a manager may see as “technical aesthetics.” What is important is the trade-off. One should resolve issues that pose a real problem for maintainability. So dependencies should be resolved if the team finds that they inhibit testing, analysis, or stability. You can solidify your case by measuring what percentage of issues arises/maintenance effort is needed in components that are tightly coupled with each other.

For example, throughput code follows complex paths that are hard to test for developers. There may be more elegant solutions that require less time and effort.

Objection: Throughput Is a Requirement

“We have a requirement for a software architecture for a layer that puts through calls.”

It is true that some architectures are designed to include an intermediate layer. Typically, this is a service layer that collects requests from one side (e.g., the user interface) and bundles them for passing on to another layer in the system. The existence of such a layer is not necessarily a problem—given that this layer implements loose coupling. It should have a clear separation of incoming and outgoing requests. So the module that receives requests in this layer:

• Should not process the request itself.

• Should not know where and how to process that request (its implementation details).

If both are true, the receiving module in the service layer has an incoming request and an outgoing request, instead of putting requests through to a specific module in the receiving component.

A large-volume service layer containing much logic is a typical code smell. In that case, the layer does not merely abstract and pass on requests, but also transforms them. Hence, for transformation, the layer knows about the implementation details. That means that the layer does not properly encapsulate both request and implementation. If throughput code follows from software architecture requirements, you may raise the issue to the software or enterprise architect.