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

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.