The Single Responsibility Principle (SRP) can be the most difficult principle to understand. The general statement that "a class should have one, and only one, reason to change" shifts the definition of responsibility to the understanding of change in an object-oriented design. There are several reasons for change; the most salient reason for changing a class is to add a new feature. As noted earlier in the Open/Closed principle section, a feature should be added as an extension rather than a modification.

In many cases, the Interface Segregation Principle (ISP) seems to provide more concrete guidance for class design than the SRP. The SRP seems to be a summary of how a class looks when we've followed the other principles.

When we review the classes defined in the preceding examples, there are some potential changes that this principle implies. In particular, the various DominoBoneYard class definitions provide the features listed here:

• Build the collection of Domino instances.
• Deal the initial hands to the players. Often this is four hands of seven dominoes, but this rule varies from game to game. This may exhaust the collection of dominoes, or it may leave some dominoes undealt.
• When there is a collection of undealt dominoes, manage the collection by allowing players to draw, to supplement their hands.

We can claim this is a single responsibility: dealing dominoes to players. There are two different ways players get dominoes (the initial deal and drawing later in the game) and both mechanisms are part of the responsibilities of a single class. This is a fairly high level of abstraction, looking at the pool of dominoes as a single thing.

We can also claim there are two responsibilities here. We can argue that creating the initial collection of Domino objects is a different responsibility from dealing Domino objects to players. We can counter-argue that adding and removing dominoes is the single responsibility of maintaining the collection contents. This is a fairly low level of abstraction.

The general guiding principles often lead to situations where expert judgment is required to make the final decision. There is no simple rule for distinguishing the level of abstraction appropriate for a design.

These principles must be used to guide the design process. They aren't immutable laws. The final decisions depend on a number of other factors, like the overall complexity of the application and the sweep of anticipated programming changes. It helps to consider the SOLID design principles as conversation starters. When reviewing a design, the splash radius around a change and the consequences of the change need to be evaluated and these principles provide a few dimensions for evaluating the quality of the design.

Let's take a look at the SOLID principle design test in the next section.