We generally think of testing as something applied to the final code (in Chapter 17, Design for Testability, we'll look at automated testing in detail). However, we can also apply a test to a SOLID design. The test is to replace a given class with an equivalent class to provide an alternative algorithm to accomplish the same purpose. If we've done our design job well, then a change to one class should have a minimal splash with few ripples.

As a concrete example, consider the Domino class shown earlier in this chapter, under the Interface Segregation Principle section. We used a NamedTuple to represent the pair of numbers. Some alternatives are possible:

• Use a frozenset to retain one or two distinct values. If there's one value in the set, the tile is actually a double, or spinner.
• Use a Counter to retain the counts for the values. If there's a single value, with a count of two, the tile is a double. Otherwise, there will be two values with counts of one each.

Do these kinds of change to the Domino class have any effect on other classes in the design? If not, then the design is nicely encapsulated. If these kinds of changes do break the design, then the design effort should continue to rearrange the class definitions in a way where the impact of a change is minimized.

In the next section, we'll build features through inheritance and composition.