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
Guideline:
-
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.
Note
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 ...
Get Building Maintainable Software, C# Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.