Введение

В коде

Если попробовать выразить этот принцип в коде, то самым простым примером будет замена множественных проверок на принадлежность к типу на абстракцию.

Например, мы пишем сервис рассылки сообщений. Он принимает текст, который надо выслать, и сервис стороннего API для отправки СМС, пушей или электронных писем. Плохо спроектированный сервис мог бы выглядеть так:

class SmsSender {
  sendSms(message: MessageText) { /* ... */ }
}

class PushSender {
  sendPush(message: MessageText) { /* ... */ }
}

class EmailSender {
  sendEmail(message: MessageText) { /* ... */ }
}

class Notifier {
  constructor(private api: SmsSender | PushSender | EmailSender) {}

  notify(): void {
    const message = 'Some user notification';

    if (this.api instanceof SmsSender) {
      this.api.sendSms(message)
    } else if (this.api instanceof PushSender) {
      this.api.sendPush(message)
    } else if (this.api instanceof EmailSender) {
      this.api.sendEmail(message)
    }
  }
}

Проблема этого кода в том, что при добавлении нового типа стороннего API — голубиной почты — нам придётся менять уже существующий код.

// ...Предыдущие классы.

// Добавили новый тип стороннего API:

class DoveSender {
  sendDove(message: MessageText) { /* ... */ }
}

class Notifier {
  constructor(private api: SmsSender | PushSender | EmailSender | DoveSender) {}

  notify(): void {
    const message = 'Some user notification';

    if (this.api instanceof SmsSender) {
      this.api.sendSms(message)
    } else if (this.api instanceof PushSender) {
      this.api.sendPush(message)
    } else if (this.api instanceof EmailSender) {
      this.api.sendEmail(message)
    } else if (this.api instanceof DoveSender) { // Последние 3 строчки —
      this.api.sendDove(message)                 // ...это новый код,
    }                                            // ...который пришлось добавить.
  }
}

Вместо этого

OCP же предлагает не проверять конкретные типы, а использовать абстракцию, которая позволит не менять код класса Notifier. Для этого мы создадим интерфейс Sender, который будут реализовывать классы SmsSender, PushSender и EmailSender:

// Интерфейс будет абстракцией, которая описывает контракт,
// по которому должны работать классы, реализующий этот интерфейс:

interface Sender {
  sendMessage(message: MessageText): void
}

class SmsSender implements Sender {
  sendMessage(message: MessageText) {
    /* То, что раньше было внутри метода `sendSms`. */
  }
}

class PushSender implements Sender {
  sendMessage(message: MessageText) {
    /* То, что раньше было внутри метода `sendPush`. */
  }
}

class EmailSender implements Sender {
  sendMessage(message: MessageText) {
    /* То, что раньше было внутри метода `sendEmail`. */
  }
}

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

class Notifier {
  constructor(private api: Sender) {}

  notify(): void {
    const message = 'Some user notification';
    this.api.sendMessage(message);
  }
}

В результате

Теперь при добавлении голубиной почты, нам уже не потребуется менять код класса Notifier, зависящего от интерфейса Sender:

class DoveSender implements Sender {
  sendMessage(message: MessageText) {
    /* То, что раньше было внутри метода `sendDove`. */
  }
}

// Код класса `Notifier` останется тем же.

Таким образом, вводя адекватную абстракцию мы «расцепляем» модули. Мы делим зоны ответственности между разными частями приложения и уменьшаем количество кода, который нужно изменять при добавлении новой функциональности.