Перейти к содержанию

Interface Segregation Principle (ISP)

ISP говорит: лучше несколько узких контрактов, чем один широкий интерфейс, от которого всем достается лишнее.

Что означает в 1С

Для 1С это обычно означает, что не нужно заставлять клиента зависеть от общего модуля или объекта, где рядом лежат:

  • чтение;
  • запись;
  • печать;
  • отправка;
  • администрирование.

Если клиенту нужна только одна часть, контракт лучше сузить.

В 1С такая сегрегация часто выполняется не отдельной конструкцией языка, а организацией модуля через области.

Например:

  • методы для внешних потребителей выносят в Программный интерфейс;
  • более узкие точки входа для других подсистем могут оформляться областью ДляВызоваИзДругихПодсистем;
  • методы для внутренних технических потребителей оставляют в СлужебныйПрограммныйИнтерфейс.

То есть сегрегация здесь выражается не только в "разных интерфейсах" как в классическом ООП, но и в том, что модуль явно показывает: какой набор методов предназначен для какого круга клиентов.

Это поддерживают и стандарты: #std455: Структура модуля, #std551: Разработка конфигураций с повторным использованием общего кода и объектов метаданных и #std644: Обеспечение совместимости библиотек.

Пример на 1С

Function GetPrintData(InvoiceRef) Export

    Return New Structure;

EndFunction

Function Export(InvoiceRef) Export

    Return "Exported";

EndFunction

#Region Program interface

Function GetPrintData(InvoiceRef) Export

    Return New Structure;

EndFunction

#EndRegion

#Region ДляВызоваИзДругихПодсистем

Function ExportForExchange(InvoiceRef) Export

    Return "Exported";

EndFunction

#EndRegion

#Region Service interface

Procedure ResetCache() Export

EndProcedure

#EndRegion

Клиент печати зависит только от GetPrintData(), а клиент экспорта только от Export(). Им не нужен общий "супер-интерфейс", в котором перемешаны обе обязанности.

Где полезен

  • в общих модулях прикладных сервисов;
  • в интеграционных шлюзах;
  • в коде форм, которым нужна только узкая часть большого API.

Когда применяют неправильно

  • когда дробление уходит слишком далеко и интерфейсов становится больше, чем смысла;
  • когда разделение не отражает реальных сценариев использования;
  • когда клиентам почти всегда нужен полный набор операций.