Overcomplicated code combines high complexity or domain significance with many collaborators. It is risky to leave untested yet difficult to unit test because its collaborators increase test maintenance costs. section 7.1 section 7.6
Classify code by complexity or domain significance and collaborator count:
- Domain models and algorithms have high complexity or significance with few collaborators, making them the best targets for valuable unit tests. section 7.1
- Controllers have many collaborators but little complexity or significance, so test them briefly through integration tests. section 7.6
- Trivial code has little complexity, significance, or collaboration and is generally not worth testing. section 7.1
- Split overcomplicated code into complex business logic and a thin controller that coordinates collaborators. section 7.6
Extracting logic from a fat controller
A fat controller performs complex or business-critical work instead of delegating it. Apply the Humble Object pattern: move the business logic into a separate class and leave a simple wrapper to coordinate dependencies. section 7.1 section 7.6
Figure 7.2. Refactor overcomplicated code by splitting it into algorithms and controllers. Ideally, you should have no code in the top-right quadrant.
Use the refactoring diagram to see overcomplicated code divided into algorithms and controllers. section 7.1
