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 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 O’Reilly online learning.

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