7: Single Responsibility Principle

Single-responsibility principleWikipedia

Historical Definition:

• A module should have one, and only one, reason to change.

• A module should be responsible to one, and only one, user or stakeholder.

A user or stakeholder are really referring to a Group - one or more people who require change. Group can be referred to as an Actor

Definition:

A module should be responsible to one, and only one, actor.

What is a "module"?

• Simplest definition is just a source file, class, or a cohesive set of functions and data structures.

• Cohesion is the force that binds together the code responsible to a single actor.

Violations

Symptom 1: Accidental Duplication

• An Employee class for a Payroll Application has methods to calculatePay, reportHours, and save

• These methods violate the SRP because they are used by three different actors.

• If these methods were to share a common algorithm to calculate overtime hours, a change requested by one actor would unintentionally impact the other.

Symptom 2: Merges

• Source files that contain many different methods often require merges when two developers (or teams) are working in the same file.

• This is even more common when the methods are responsible to different actors.

• When multiple people are changing the same source file for different reasons.

• Solution: Separate code that supports different actors.

Solutions

Each solution moves the functions into different classes.

1. We can separate the Functions from the Data using Employee, PayCalculator, HourReporter, and EmployeeSaver.

2. Some developers prefer to keep the most important business rules closer to the data (e.g rich domain model). Employee becomes a facade, using separate classes internally to perform the operations.

Conclusion

• The SRP is about Functions and Classes.

• At the level of components, it becomes the Common Closure Principle.

• At the architectural level, it becomes the Axis of Change responsible for the creation of Architectural Boundaries.