Table of Contents
Interface Segregation Principle
Variants and Alternative Names
Context
Principle Statement
Don't expose methods to your client, methods that they don't use.
Description
Rationale
Exposing functionality that the client class does not need at most a security risk and at the very least noise for the client class. You don't want your class's clients to recompile if some method they don't use changed.
Strategies
Caveats
See section contrary principles.
Origin
Evidence
Relations to Other Principles
Generalizations
Specializations
Contrary Principles
Complementary Principles
Principle Collections
Examples
Coffee Maker
Let's say your coffee maker logic receives input from various sensors which are external components to it. Eg: tankOutOfWater() and waterHeated() from the WaterTank and HeatSensor components respectively. You don't want the WaterTank component to be able to access the waterHeated() method. You can do this, by making your business logic implement the interfaces TankObserver and TemperatureObserver, each exposing the methods that can be accessed by each component. Then the component only knows how to talk to the interface, so the rest methods of the concretion are transparent to it.
Description Status
Further Reading
Discussion
Discuss this wiki article and the principle on the corresponding talk page.