“A class should have only one reason to change.”

—R. Martin

From decades ago, we know that we should try to separate cohesive responsibilities to one module or class. Each module or class must have one single responsibility or reason for change. This principle is related to other valuable knowledge pills as «high-cohesion», «separation-of-concerns», for example.

The consequences of this principle, should be a large set of little classes, with a few high-cohesive methods, but with an enormous potential for reuse. This principle goes hand-to-hand with the ISP as every set of cohesive functions and properties should define its own type. In the example below, instead of the first version, we encourage to use the second solution under the separation line.

The example above is used on purpose. It’s a common decision in software designs to mix domain logic with persistence. Many self-called ORMs systems dance around that mingled design, bringing to the domain layers primary and foreign keys properties or persistence behavior (save, delete, etc.). Although the proposed solution seems radical, it promotes reusability, complies with high-cohesive elements, and “separation of concerns”. The domain object EntityType (that represent a type) is separated from the reusable classes and interfaces (IObjectIdentifier, IPersistable, and PersistentObject) of persistence, and its effective period qualities (IActivable).

How to comply with this recommendation? Frequent solutions are in the scope of the Repository pattern or a persistence subsystem (as separate modules), that allow the complete separation of code from both perspective. The preferable path is to develop a persistence module that separates the O/R mapping with no code dependencies, that might be reused for any business object persistence. This type of solution should use external resources to map the object and relational worlds, without extending the domain classes or the persistence mechanisms.

As I like to emphasis, the object-orientation could be used elsewhere for other software technologies. This principle could be applied to tables in relational databases, for example. The normalization rules are one of those mechanism that respect the SRP in the first form:  don’t repeat data at the horizontal axis (columns) and the vertical axis (rows). Each entity, , its attributes and instances, should be dedicated to one single value or responsibility. The factor of change for a table should only one new, undiscovered, cohesive property, but not multiple properties from different subjects.