Ссылка. Interface Segregation Principle

http://sergeyteplyakov.blogspot.ru/2014/08/interface-segregation-principle.html

Ну ОЧЕНЬ хорошо по-моему...

"Во-первых, может появиться необходимость выделить интерфейс для класса целиком. Это бывает необходимым для «изменчивых» зависимостей (классов, взаимодействующих с внешним миром) или для стратегий (когда нам нужно полиморфное поведение, определенное интерфейсом).

Во-вторых, мы можем выделить некий аспект текущего класса, который покрывает не весь функционал, а лишь его часть, т.е. его отдельный аспект. Примером может служить добавление классу «маркерных» интерфейсов, типа ICloneable, IComparable<T>, IEquatable<T> и т.п. При этом выделение маркерных интерфейсов обычно требуется для использования класса в новом контексте (класс Person реализуется IComparable<T> для корректного использования вSortedList).

В-третьих, может потребоваться выделение специализированных бизнес-интерфейсов, когда станет очевидным, что наш класс используется в нескольких разных контекстах. Например, когда репозиторий используется разными клиентами двумя способами: одна группа клиентов использует лишь операции для чтения данных, а другая группа – для обновления. Обычно это говорит не столько о нарушении ISP, сколько о наличии скрытой абстракции (IRepositoryReader и IRepositoryWriter).

В-четвертых, нам может потребоваться использовать несколько разных классов из разных иерархий наследования полиморфным образом (именно этот пример был показан в предыдущем разделе). При этом обычно такое выделение происходит во время рефакторинга, когда необходимость в этом становится очевидной:

«Ага, вот у нас есть два класса, которые мы могли бы использовать совместно, но они уже унаследованы от разных базовых классов. Давайте выделим для каждого из них единый интерфейс и избавимся от богомерзких if-else»."