Aaron Proctor

The incoherent braindump of a software developer

Interface Segregation Principle

This is part 4 of a series of blog posts on the SOLID principles – five fundamental principles of object-oriented software design.

The Interface Segregation Principle

Clients should not be forced to depend upon interfaces that they do not use.

The Interface Segregation Principle is all about making your interfaces smaller and more focused. There’s little point in exposing large numbers of methods in a system to all clients – indeed, doing so can lead to a tightly coupled system which is difficult to change and test.

Consider the dependency which the Player class has on the IGameBoard interface. Is this really necessary? The only GameBoard related services needed by the player is the MovePlayer method – is there any need to give the Player object access to the size of the gameboard? Any time you give a client access to more services than it needs, you make it more difficult to modify and increase dependencies.

We can factor out the MovePlayer functionality from the IGameBoard interface and into a new, more specific interface:

And have the GameBoard class implement our new interface:

Now the Player class no longer depends on the entire GameBoard interface and there’s no danger of other developers breaking the Player class by seemingly unrelated changes to the GameBoard.

Similarly, any other clients of the GameBoard class can be treated the same way. Now we no longer have a monolithic “God Interface” to work with the game board system. Just like with classes, large and omnipotent interfaces are harder to maintain.

Post a comment