Перейти к основному содержимому

Мост (Bridge)

Теория​

Мост - позволяет изменять реализацию и абстракцию, для чего они размещаются в двух разных иерархиях классов. Полезен в ситуациях с возможностью независимого изменения интерфейса и реализации.

Преимущества:

  • Логическое отделение реализации от интерфейса.
  • Абстракция и реализация могут расширяться независимо друг от друга.
  • Изменения в конкретных классах абстракции не отражаются на стороне клиента.
ПРИМЕЧАНИЕ:

Хотя паттерн Мост традиционно определяется через конкретную структуру классов, в платформе 1С его можно рассматривать в первую очередь как общий гибкий принцип проектирования.

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

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

Поэтому в 1С Мост зачастую "растворен" в архитектуре и может присутствовать везде, где есть разделение интерфейса и реализации.

БСП​

Представим упрощенный пример, что в конфигурации есть подсистема Регламентированная отчетность", которая позволяет формировать различные отчеты для предоставления в контролирующие органы.

Эта подсистема использует общие механизмы:

  • СозданиеОтчета()
  • ЗаполнениеОтчета()
  • ПроверкаОтчета()
  • ПодписаниеОтчета()
  • ОтправкаОтчета()

Они описаны в специальном общем модуле РегламентированнаяОтчетность.

А конкретная реализация формирования разных отчетов (например, НДФЛ, бухгалтерский баланс, отчет о финрезультатах и т.д.) вынесена в отдельные отчеты.

То есть общий модуль - это наша абстракция в терминах паттерна Мост, а отчеты - конкретные реализации этой абстракции.

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

Примеры​

Код​

Главная идея паттерна Мост - отделить абстракцию от ее реализации, чтобы они могли изменяться независимо.

В 1С нет понятий классов и интерфейсов, поэтому будем использовать обработки и модули:

  1. Общий модуль обмена - содержит вспомогательные функции, которые могут использовать разные обработки. Это наша абстракция.

Например:

Функция ДанныеИзИсточника(Источник) Экспорт
Функция ДанныеВИсточник(Источник, Данные) Экспорт
  1. Обработки - реализуют конкретную бизнес-логику работы с данными. Это наши реализации.

Например:

// Обработка.ОбменДокументооборот
Функция ОбработкаДанных()

    Данные = ПолучитьДанныеИзИсточника("1СДокументооборот");

    //...обработка данных...

    ЗаписатьДанныеВИсточник("1СДокументооборот", Данные); 

КонецФункции
  1. Вызов из других обработок или сценариев:
Данные = ОбработкаДокументооборот.ОбработкаДанных();
//работа с данными

Таким образом мы разделяем общую логику (модуль) от реализации конкретной бизнес-логики в обработках. И можем расширять их независимо.