User Tools

Site Tools


principles:interface_segregation_principle

This is an old revision of the document!


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.

principles/interface_segregation_principle.1602499208.txt.gz · Last modified: 2020-10-12 12:40 by 159.69.186.191