Building Maintainable Software, C# Edition

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