Chapter 7. Couple Architecture Components Loosely

There are two ways of constructing a software design: one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.

C.A.R. Hoare

Guideline:

  • Achieve loose coupling between top-level components.

  • Do this by minimizing the relative amount of code within modules that is exposed to (i.e., can receive calls from) modules in other components.

  • This improves maintainability because independent components ease isolated maintenance.

Having a clear view on software architecture is essential when you are building and maintaining software. A good software architecture gives you insight into what the system does, how the system does it, and how functionality is organized (in component groupings, that is). It shows you the high-level structure, the “skeleton” so to speak, of the system. Having a good architecture makes it easier to find the source code that you are looking for and to understand how (high-level) components interact with other components.

This chapter deals with dependencies on the component level. A component is part of the top-level division of a system. It is defined by a system’s software architecture, so its boundaries should be quite clear from the start of development. As it is touching upon the software architecture domain, it may be outside of your direct control. However, the implementation of software architecture ...

Get Building Maintainable Software, C# Edition now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.