Принципы ООП в 1С на примере реализации pattern Decorator

Для начала ознакомимся с UML диаграммой шаблона decorator

Основной элемент в данном примере это агрегация (, про отношения в UML диаграмме классов можно почитать тут), суть данного шаблона в том, что он работает по аналогии с матрешкой, оборачивая базовый класс и дополняя его новой функциональностью (второе название данного паттерна Wrapper, что говорит само за себя).

Давайте "на берегу" определимся с понятиями интерфейс и класс в 1С. Таких понятий в 1С нет, однако если провести параллели, то наиболее близкая к классу сущность, это обработка. С интерфейсом сложнее, можно конечно реализовать паттерн и без интерфейса, но тогда не будет той необходимой и полезной абстракции. В статье Строим "фасады" в 1С автор использовал для аналогии интерфейса общие модули, общий модуль не очень подходит для данной задачи, по факту это будет просто обертка вокруг класса. В данном примере в качестве интерфейса я буду использовать так же обработку. 

Приступим к реализации. 

Например, перед нами стоит задача реализовать алгоритм поиска контрагента.

создаем обработку с экспортным методом в модуле объекта НайтиКонтрагента(ИНН, КПП); вызов из кода будет такой

Объект = Обработки.ПоискКонтрагента.Создать();
Контрагент = Объект.НайтиКонтрагента(ИНН, КПП); // Какой-то ИНН и какой-то КПП

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

Давайте подумаем, какую роль выполняет интерфейс в ООП? Как нам подсказывает вики 

устанавливают взаимные обязательства между элементами программной системы

Если своими словами, то объявленные методы в интерфейсе обязательно должны быть реализованы в каждом классе который реализует этот интерфейс.

Для реализации интерфейса создаем новую обработку "ПоискКонтрагентаИнтерфейс". Содержащая реквизит РеализующийОбъект, тип ОбработкаОбъект.ПоискКонтрагента (или составной, для случаев если данный интерфейс имплементируют несколько классов)

Содержимое модуля объекта

#Область ПрограммныйИнтерфейс

Функция Имплементация(Объект) Экспорт 
	 Методы = Новый Массив();
	 Методы.Добавить("НайтиКонтрагента");
	 
	 ПроверитьСуществованиеМетодов(Объект, Методы);
	 ЭтотОбъект.РеализующийОбъект = Объект;

	 Возврат ЭтотОбъект;
 КонецФункции
 
 Функция НайтиКонтрагента(Данные) Экспорт 
	 Если ЭтотОбъект.РеализующийОбъект = Неопределено Тогда
			ВызватьИсключение "Интервейс не имплементирован";	 
	 КонецЕсли;
	 
	 Возврат ЭтотОбъект.РеализующийОбъект.НайтиКонтрагента(Данные);
 КонецФункции
 
 
 #КонецОбласти

 
 #Область СлужебныеПроцедурыИФункции


Процедура ПроверитьСуществованиеМетодов(Объект, Методы)
	ОтсутствующиеМетоды = Новый Массив();
	Для Каждого Метод Из Методы Цикл
		Попытка
			Параметры = Новый Структура("РежимПроверки", Истина);
			 Выполнить(СтрШаблон("Объект.%1(Параметры)", Метод));
		Исключение
			 ОтсутствующиеМетоды.Добавить(Метод);
		КонецПопытки;
	КонецЦикла;
	
	Если ОтсутствующиеМетоды.Количество() > 0 Тогда
		ВызватьИсключение СтрШаблон("В обработке отсутствуют методы:
																	|%1", СтрСоединить(ОтсутствующиеМетоды, Символы.ПС));	
	КонецЕсли;
	
КонецПроцедуры

#КонецОбласти

Метод Имплементация - основной, он делает проверку на существования в реализующем классе необходимых методов (правда коряво эта проверка происходит), так же инициализирует значением реквизит РеализующийОбъект.

Метод НайтиКонтрагента - по сути редирект на метод объекта, это нужно, что бы можно было делать вызов метода, используя интерфейс.

В обработку ПоискКонтрагента добавляем реквизит БазовыйОбъект, тип составной (типы от которых может наследоваться этот класс) модуль объекта обработки добавляем методы Имплементация().

Функция Имплементация(ИнтерфейсИмя) Экспорт 
	Возврат Обработки[ИнтерфейсИмя].Создать().Имплементация(ЭтотОбъект);
КонецФункции

и Наследовать() 

Функция Наследовать(БазовыйОбъект) Экспорт 
	ЭтотОбъект.БазовыйОбъект = БазовыйОбъект;	
	Возврат ЭтотОбъект;
КонецФункции

 На текущем этапе БазовыйОбъект нам по большому счету не нужен, но давайте придерживаться одного шаблона, не важно наш класс наследуется от другого или нет, структура должна быть шаблонная.

В начале метода НайтиКонтрагента делаем проверку

Если ДанныеВерсии.Свойство("РежимПроверки") И ДанныеВерсии.РежимПроверки Тогда
  Возврат Неопределено;	
КонецЕсли;

Это нужно для метода ПроверитьСуществованиеМетодов (который у нас в модуле Интерфейсы). Ну нет у 1С нормального способа проверить существует ли метод в модуле объекта или нет.

Вот так изменится вызов метода НайтиКонтрагента

Данные = Новый Структура("ИНН, КПП", КакойтоИНН, КакойтоКПП); // Входящий параметр теперь один, структура.
Интерфейс = Обработки.ПоискКонтрагента.Создать().Имплементация("ПоискКонтрагентаИнтерфейс"); // ПоискКонтрагентаИнтерфейс - имя обработки интерфейса.
Контрагент = Интерфейс.НайтиКонтрагента(Данные); // Вызов через интерфейс

Зачем такие сложности скажите вы, зато теперь мой "интерфейс" могут имплементировать разные обработки разной структуры и разными методами, но мы 100% уверены, что у любой обработки есть нужный нам метод и мы можем вызвать его используя интерфейс.

На данном этапе мы реализовали эту часть диаграммы: 

Теперь реализуем сам декоратор.

Пусть наш декоратор расширяет алгоритм таким образом, что бы в случаи если не найден контрагент, он создавался.

Для этого создаем еще один класс обработку Декоратор1, копия обработки ПоискКонтрагента 

Единственное изменение, это доработанный метод НайтиКонтрагента(), доработан он таким образом:

Функция НайтиКонтрагента(Данные) Экспорт 
	Если ДанныеВерсии.Свойство("РежимПроверки") И ДанныеВерсии.РежимПроверки Тогда
		Возврат Неопределено;	
	КонецЕсли;

	Версия = БазовыйОбъект.НайтиКонтрагента(Данные); // Вызываем поиск базового объекта.
// Дополнение которое привносит декоратор.
	Если Не ЗначениеЗаполнено(Версия) Тогда
		Версия = СоздатьКонтрагента(ДанныеВерсии);	
	КонецЕсли;
	
	Возврат Версия;
КонецФункции

Функция СоздатьКонтрагента(ДанныеВерсии)
	// Создаем.	
	Сообщить("Создаем новый элемент справочника"); // Для демонстрации, что вызов есть.
КонецФункции

Тип реквизита БазовыйОбъект составной, по сути все типы от которых может наследоваться этот класс, а именно ПоискКонтрагента, ПоискКонтрагентаИнтерфейс. Данный класс так же реализует интерфейс ПоискСправочникаИнтерфейс, по этому у его реквизита РеализующийОбъект нужно сделать так же составной тип в который входит новый класс. Кстати это удобней делать через определяемые типы. 

Вызов будет таким:

Данные = Новый Структура("ИНН, КПП", КакойтоИНН, КакойтоКПП); // Входящий параметр теперь один, структура.
Интерфейс = Обработки.ПоискСправочника.Создать().Имплементация("ПоискСправочникаИнтерфейс");
Декоратор1 = Обработки.Декоратор1.Создать()
								.Наследовать(Интерфейс)
								.Имплементация("ПоискСправочникаИнтерфейс");
Контрагент = Декоратор1.НайтиКонтрагента(Данные);

Обращаю внимание, что декоратор наследуется от интерфейса и новый объект так же имплементирует ПоискКонтрагентаИнтерфейс

Если мы захотим еще обернуть, то просто создаем копию декоратора 1 и реализуем в нем свои изменения, в моем примере это вывод еще одного сообщения (не забываем про типы реквизитов БазовыйОбъект и РеализующийОбъект)

Функция СоздатьКонтрагента(ДанныеВерсии)
	Сообщить("Что-то делаем"); // Для демонстрации, что вызов есть.
КонецФункции

Вызов изменится так: 

Данные = Новый Структура("ИНН, КПП", КакойтоИНН, КакойтоКПП); // Входящий параметр теперь один, структура.
Интерфейс = Обработки.ПоискСправочника.Создать().Имплементация("ПоискСправочникаИнтерфейс");
Декоратор1 = Обработки.Декоратор1.Создать()
								.Наследовать(Интерфейс)
								.Имплементация("ПоискСправочникаИнтерфейс");

Декоратор2 = Обработки.Декоратор2.Создать()
								.Наследовать(Декоратор1)
								.Имплементация("ПоискСправочникаИнтерфейс");
Контрагент  = Декоратор2.НайтиКонтрагента(Данные);

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

Вот результат 

хотя как мы видим вызов метода происходит один раз.

В итоге у нас вышла такая реализация

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

Спасибо за внимание!