Essential Design Tips (Continued)

Enforce Encapsulation
Most software developers understand the concept of encapsulation, but in many cases encapsulation does not remain a priority. Problems with slacking on encapsulation (such as a lazy designer) usually manifest themselves later in the application lifecycle. The application might work fine now, but what happens when change is necessary? An implementation that is not completely hidden through an abstract interface can "bleed" across component boundaries (see Figure 4). In turn, changes that should be isolated instead propagate across the architecture.

Recently I gave my Java students a homework assignment to implement an interface exposing methods that dealt with a collection of data. I was surprised by the fact that, although each solution yielded the correct output, no two implementations were the same—most were not even similar. The important point is that the implementation details for each student's solution were transparent to the test driver (client) program. This enabled seamless testing without changing any code. This is a classic example of the ease with which different implementations can be "plugged in" when the implementation details are hidden.

Minimize Dependencies
With respect to dependencies, a "less is more" approach is the way to go. As the number of relationships increases for a given software component, so does the complexity. Similar to the discussion in the previous tips, component dependencies usually bite later in the application lifecycle. When a software component has a lot of "friends" (is highly dependent), be aware of several adverse side effects:

• Difficulty understanding functionality: To thoroughly understand the functionality of one component, you must follow and understand all dependencies and related components as well.
• More difficult maintenance: Requirements for changes and/or enhancements increase the potential for change propagation across the architecture.
• Hindered reuse: Components with a high degree of dependency can't be taken in isolation—reusing functionality requires dragging along all dependencies.

Work toward adaptable, reusable, simplified software designs by reducing relationships among software components to the extent possible.

Developing good, sound software designs is difficult, yet it is the challenge that makes it fun. To this end, the first step is being aware of various design strategies. The second step is understanding the benefits of a good design and the potential pitfalls when sound design techniques are not used. Keep these design tips at the forefront, and unleash your design skills on new software challenges.

About the Author
Jason Byassee is a software architect and technology advisor at Northrop Grumman Mission Systems. His work spans a diverse set of production and research platforms, including data integration for Web-based systems, distributed agent architectures, genetic algorithms, and knowledge management systems. Contact Jason at jason.byassee@ngc.com.