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 Java.
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, Java 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.