202204291512 Single responsibility

The single responsibility principle of the 202204272244 SOLID design principles for software development, which states:

There should never be more than one reason for a class to change.¹

This is a challenging one to put into practice because "one reason" can be interpreted in many ways. For instance, imagine we have a repository class that abstracts storage of data from our domain logic. A well-factored class would naturally have at least 2 reasons to change:

1. The shape of the data needs to be different. E.g., we add a column to our DB table.
2. The underlying storage mechanism needs to change. E.g., we are moving from MySQL to PostgreSQL.

Nonetheless, we should strive to make maintainable units of code that are isolated, well tested, and don't become large single points of failure. This principle is good to strive for with the understanding that there is some nuance here.