- Modularity
- Modules
- Modularity in Software Systems
- Modularity, Complexity, and Coupling
- Coupling in Modularity
- Key Takeaways
- Quiz
This chapter is from the book
This chapter is from the book
This chapter is from the book
Coupling in Modularity
Many aspects of modularity can be understood only by considering the modules not as individual entities, but by examining them in relation to one another. This was demonstrated in the Deep Modules section earlier: Even perfectly “deep” modules can still introduce complex interactions. As Alan Kay said, the big idea of object-oriented programming is messaging, not classes;8 in other words, the relationships and interactions between objects.9 Traditionally, when systems are designed the main focus is on the components, or boxes. But what about the arrows and lines connecting them?
The modularity of a system cannot be evaluated by examining designs of individual modules in isolation. The goal of modular design is to simplify the relationships between components of a system. Hence, modularity can only be evaluated in the scope of the relationships and interactions between the components. The knowledge that is shared among the components controls whether the overarching system will be more modular or more complex. Coupling is the aspect of a system that defines what knowledge is shared between components of a system. Different ways of coupling components share different types and amounts of knowledge. Some will increase complexity, while others will contribute to modularity.
This is a good time to mention the counterpart of coupling: cohesion. The concept of cohesion was introduced in tandem with coupling in Structured Design (Yourdon and Constantine 1975). Cohesion refers to the degree to which the elements inside a module belong together. In other words, it’s a measure of how closely the responsibilities of a module are related to each other. High cohesion is generally seen as a desirable characteristic because it promotes a single, well-defined purpose for each module, improving understandability, maintainability, and robustness.
Under the hood, however, cohesion is based on coupling. Some software engineers even refer to cohesion as “good coupling.” That’s my preferred approach as well. The chapters in Part II, Dimensions, scrutinize how coupling affects system design and the dimensions in which effects of coupling can be observed. Later in the book I will combine these insights into a concise framework for guiding modular design that will also reflect cohesion of the system’s modules.