Essential Design Tips (Continued)

Use Lightweight Components
A software component should capture only one key piece of functionality. Although this is not a novel concept, you usually find surprisingly expansive components in most software applications. Large, complex components promote rigid architectures that inhibit adaptability and hinder reuse.

Consider designing an enterprise application that integrates data (such as a data warehouse) from multiple, disparate sources. I worked this task with several colleagues recently. In considering a design, it was first suggested that we take an approach like that illustrated in Figure 1.

There are several problems with combining discrete functionality within a single software component—Extract, Translate, and Load (ETL) in this case. First, pieces of functionality will certainly be duplicated among the ETL components. If and when a change is required, it must be made and managed in multiple places. This is a maintenance nightmare.

Second, think about reuse. Software components are rarely reusable when built to "do it all." The goal is to decompose functionality and create many lightweight components vs. a smaller number of heavyweight components. Figure 2 depicts a far better solution where the E, T, and L functionality is decomposed into separate components.

Leverage Abstractions
Abstraction is probably the single most powerful software design technique. Although the concept is widely understood, in many cases abstraction is either missing or scarcely used. A software design based on abstractions provides the flexibility that allows a system to adapt and meet evolving requirements and future needs. When I design a software component, I think of generalizations as opposed to the specific application context.

Consider the ETL application (see Figure 2). Say, for example, that the data provided by System A changes from a database dump format to XML. Ideally, you would like the ability to "swap out" the current translator and add a new XML translator without any impact to the existing system. You can accomplish this by leveraging abstractions based on the Strategy design pattern (see Figure 3 and Gamma, et al. in Resources).

In the requisite text on object-oriented design patterns (see Gamma, et al. in Resources), abstraction is the common thread among the most popular patterns (Composite, Strategy, Observer, and so on). Design software component relationships based on concepts rather than implementations. For a thorough discussion of interface design leveraging abstraction and design patterns, see "The Philosophy of Interface-Driven Design" in Resources.