Join Steven Lott for an in-depth discussion in this video Introduction to interface segregation, part of S.O.L.I.D. Programming Principles.
- View Offline
- The first of the solid design principles and perhaps the most useful is the interface segregation principle. The interface segregation principle says no client should be forced to depend on methods is does not use. Stated more positively, a client should depend on the smallest set of interface features, the fewest methods and attributes. A class needs to be designed so that collaborators have the narrowest interface.
If a class has too many methods, the client code is then bound to methods it does not need. Because of Python's flexibility, it's easy to ignore this principle. Python doesn't have a compiler that does static type checking, so it doesn't obsess over all the methods and whether or not a collaborator is properly compatible with them. For Python, interface segregation is a manual effort. Keeping focus on the needs of a collaborating class will tend to drive the unit test cases.
The parts of the interface that don't support a collaborating class won't require much testing and this is a hint these features are more problem than solution. The example card and shoe classes from the previous section had three unrelated sets of features. Creating a deck or shoe of card instances. Shuffling and dealing cards. And figuring the points of each card to compute a sum. Does a client class really need all of this? Or did that design mash too much into a single class? To simulate the player decisions in blackjack, the focus should be on the few actions the player can take.
This doesn't involve building a deck. May not even involve shuffling. The methods for building a deck and shuffling are present to assure that the results have good fidelity with real world play, but they're not critical elements of playing out hands to validate a strategy. Clearly, this interface needs to be decomposed. Based on interface segregation, it's clear there needs to be a generic concept of card with rank and suit. This is a minimal interface, shared by all card related processing.
There's also a generic concept of deck. A collection that shuffles and deals cards. This is a minimal interface shared by all processing that involves decks or shoes. The game specific issues can be features of sub-classes of the abstract card. For blackjack, there can be three sub-classes for aces, number cards, and face cards. For a game like cribbage, a different set of sub-classes will be needed to compute the point values of cards. There's no need to bend or break an existing class to add a new feature set to our simulation.
The interface segregation assures that any ripples from a change to one game have no impact on any of the other games.
To incorporate SOLID into your own development workflow, Steven Lott has prepared a series of lessons that break down the principles one by one, with real-world examples. Learn how to use these principles in the design process, and to test the strength of your code along the way. Steven uses Python to demonstrate the concepts, but they're useful for any object-oriented programming language.
- An overview of SOLID principles
- Segregating code into client-specific modules
- Testing code by substituting subtypes for base classes
- Keeping software open for extension but closed to modification
- Eliminating dependencies on details
- Assigning one responsibility to each class
- Using SOLID principles in the design process