В идеальном мире

В идеально спроектированной системе сущности зависят только от тех интерфейсов, функциональность которых реализуют. Чаще всего это приводит к дроблению интерфейсов на меньшие. Рассмотрим на примерах.

«Пустая» реализация

Допустим, у нас есть класс Programmer, который описывает программиста из офиса некоторой компании. Сотрудники пишут код и иногда едят пиццу, которую компания заказывает в офис.

interface Progammer {
  writeCode(): void
  eatPizza(slicesCount: number): void
}

class RegularProgrammer implements Progammer {
  constructor() {/*...*/}
  writeCode(): void {/*...*/}
  eatPizza(slicesCount: number): void {/*...*/}
}

Через какое-то время компания начала нанимать фрилансеров, которые работают удалённо и пиццу не едят. Если мы используем тот же интерфейс, то класс Freelancer должен будет реализовать метод eatPizza, хотя он ему и не нужен — это «пустая» реализация интерфейса.

class Freelancer implements Progammer {
  constructor() {/*...*/}
  writeCode(): void {/*...*/}
  eatPizza(slicesCount: number): void {
    // здесь будет пусто —
    // это сигнал, что интерфейс надо дробить
  }
}

Разделение интерфейса

Мы можем избежать проблемы из примера выше, если разделим интерфейс Progammer. Мы можем поделить его на две роли: CodeProducer и PizzaConsumer.

interface CodeProducer {
  writeCode(): void
}

interface PizzaConsumer {
  eatPizza(slicesCount: number): void
}

Теперь и RegularProgrammer, и Freelancer будут реализовывать только те интерфейсы, которые им действительно нужны:

class RegularProgrammer implements CodeProducer, PizzaConsumer {
  constructor() {/*...*/}
  writeCode(): void {/*...*/}
  eatPizza(slicesCount: number): void {/*...*/}
}

class Freelancer implements CodeProducer {
  constructor() {/*...*/}
  writeCode(): void {/*...*/}
  // метод eatPizza уже не нужен
}

Сравнение с SRP, влияние на LSP

ISP можно представлять как SRP для интерфейсов. Дробление интерфейсов действительно заставляет делить ответственность между ними.

Если мы применяем ISP, получаем больше интерфейсов с меньшим количеством методов в каждом. Если мы применяем SRP, получаем больше модулей с меньшим количество методов в каждом. Применение обоих принципов разом заставляет делать контракты между модулями проще, что снижает вероятность нарушения LSP.

Материалы к разделу

Вопросы