Chapter 6. Separate Concerns in Modules
In a system that is both complex and tightly coupled, accidents are inevitable.
Charles Perrow’s Normal Accidents theory in one sentence
Avoid large modules in order to achieve loose coupling between them.
Do this by assigning responsibilities to separate modules and hiding implementation details behind interfaces.
This improves maintainability because changes in a loosely coupled codebase are much easier to oversee and execute than changes in a tightly coupled codebase.
The guidelines presented in the previous chapters are all what we call unit guidelines: they address improving maintainability of individual units (methods/constructors) in a system. In this chapter, we move up from the unit level to the module level.
Remember that the concept of a module translates to a class in object-oriented languages such as C#.
This module-level guideline addresses relationships between classes. This guideline is about achieving loose coupling.
We will use a true story to illustrate what tight coupling between classes is and why it leads to maintenance problems. This story is about how a class called
UserService in the service layer of a web application started growing while under development and kept on growing until it violated the guideline of this chapter.
In the first development iteration, the
UserService class started out as a class with only three methods, the names and responsibilities of which are shown in this ...