As Martin states, this principle deals with the inconveniences of "fat" interfaces. And the problem arises when the interfaces of the class can be logically fragmented into distinct groups or methods.
In this case, if there is more than a client of our application, chances are that some clients are connected to a functionality they never use.
Back to our demo again: the mere review of the definition reveals that our system has some defects from the point of view of this principle.
First, we're implementing a method that is only used by a type of a SportCar client: the Mercedes. The other brands don't use it. In case a new condition arises for a different brand, new options should be created.
So, this marks a difference in the way in which we can categorize our cars: those who notify the user interface about SpeedLimit and those who don't. We should start by redefining our ISportCar interface to cover only those aspects that are commonly used by any client. This...