Добрый день!

Есть обработка, которая конвертирует данные из старых баз данных в новую.
На данный момент все сделано для конвертации контрагентов.

Я постарался сделать функции\процедуры "универсальными" и перенес их в общие модули, они "отвязаны" от формы. Эти модули сделаны "серверными", в них просто передаются данные и обрабатываются.
В итоге весь код разбит на следующие общие модули:
— Модуль "Сопоставление" который делает сопоставление старых и новых данных (по ID-шникам и по указанному  набору реквизитов)
— Модуль "Маппинг_Контрагенты" делает непосредственно конвертацию данных старого контрагента в нового и вызывает запись нового контрагента в базу с помощью модуля "РаботаСДанными_Контрагенты".
— Модуль "РаботаСДанными" - читает и записывает,
— Модуль "ВзаимодействиеСФормой" - возвращает для формы ТаблицуЗначений, в которой отображаются сопоставленные данные для проверки пользователем. По командам пользователя из Формы вызывает "Маппинг" и запись данных с помощью модуля "РаботаСДанными".

В целом все сделано и все работает.

Теперь нужно сделать доработку таким образом, чтобы применить эту обработку для конвертации другого справочника из старой БД - номенклатуры.
Суть обработки номенклатуры такая же как и обработка контрагентов. Отличается только часть полей.
Форма на 90% не поменяется, поменяются только часть колонок в отображаемых таблицах.
Модули "Сопоставление" и "ВзаимодействиеСФормой" вообще не меняются, они "универсальные".

Значительно поменяется только реализация модулей "Маппинг" и "РаботаСДанными".
Программный код реализаций для обработки товаров уже написан - я сделал новые модули "Маппинг_Номенклатура" и "РаботаСДанными_Номенклатура". В этих модуля точно такие же методы, как и в модулях для работы с контрагентами.

Осталось только при загрузке формы как-то сделать так, чтобы "универсальные" модули вместо модулей контрагентов ("Маппинг_Контрагенты", "РаботаСДанными_Контрагенты") использовали бы модули для работы с номенклатурой "Маппинг_Номенклатура" и "РаботаСДанными_Номенклатура".
А как это сделать?

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

Как это можно сделать в 1С?

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

Сделай универсальную конвертацию по реквизитам
Ну там простые типы, ссылочные и т.д.

И тогда пофиг будет Контрагенты или Номенклатура

"В идеале, обработку хотелось бы сделать сделать вообще "универсальной""
КД2 вам в помощь.

Самый простой вариант - это где-то выставить глобальный признак справочника.
И написать во всех "универсальных" методах что-то типа


Если глОбрабатываемыйСправочник = "Контрагенты" Тогда
    ОбщийМодуль.Маппинг_Контрагенты.Выполнить(лСтарыеДанные, лНовыеДанные);
ИначеЕсли глОбрабатываемыйСправочник = "Номенклатура" Тогда
    ОбщийМодуль.Маппинг_Номенклатура.Выполнить(лСтарыеДанные, лНовыеДанные);
КонецЕсли;


Но как-то это ... "некрасиво" что ли.

А также непонятно где сделать этот глобальный признак, чтобы он был "виден" в общих модулях?
Они же "независимы" от вызывающей их обработки. Кроме того, чисто теоретически можно запустить одновременно обе обработки: и для загрузки контрагентов и для загрузки номенклатуры.
Тогда придется передавать этот признак как параметр во все модули и во все методы этих модулей?

У 8-ке уже давно есть модуль менеджера

(1),(2) Конвертация, которая сейчас есть она устраивает, и она достаточно сложная. Там просто так не сконвертируешь "РеквизитСтарый - РеквизитНовый". Там например из трех записей из старых БД собирается один новый контрагент.

Мой вопрос не в этом.
Все уже есть, модули написаны. Нужно как-то их "подменять" в зависимости от вызывающей обработки.
Как этом можно сделать?

На C# это делается просто с помощью классов, наследования, фабрик.
А в 1С как?

(4) А можно поподробнее?
Как применить этот модуль менеджера, чтобы он помог в моей ситуации?

Бегло пробежался, понятно что это такое.
Проблема в том, что мои "универсальные" модули не знают ни про форму, ни про объекты. То есть для них модуль менеджера недоступен.

Почеме некрасиво-то?
Вся БСП из этого состоит.

Если Условие1 Тогда
    Модуль = Вычислить(ИмяМодуля)

И далее по всем кочкам.

(7) А "ИмяМодуля" откуда туда попадет? Передавать как параметр?

Тогда придется составлять список всех нужных модулей, и во все методы передавать этот список.

(8)
Выше написали: модуль менеджера.
Имя составляется из метаданных объекта.

ТекстЗапроса = Документы[ОбъектМетаданных.Имя].ЭкпортнаяФункцияМодуляМенеджераТекстЗапроса();

(4) У внешних обработок не бывает модуля менеджера, к сожалению

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

(10) И как быть?
Что посоветуете для решения моей задачи?

(3) Может лучше так?

Если глОбрабатываемыйСправочник = "Контрагенты" Тогда
    ОбщийМодульОбработки = ОбщийМодуль.Маппинг_Контрагенты;
ИначеЕсли глОбрабатываемыйСправочник = "Номенклатура" Тогда
    ОбщийМодульОбработки = ОбщийМодуль.Маппинг_Номенклатура;
КонецЕсли;
ОбщийМодульОбработки.Выполнить(лСтарыеДанные, лНовыеДанные);

(13) Да, так лучше.

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

Явно в этом подходе что-то неправильно.

Правильно понимаю что очень хочется Полиморфизм в 1С?
Вроде как ВР доказывал что в 1С полноценное ООП ))

(11) в модуле объекта Контрагенты, Номенклатура итд, в экспортном методе расписываешь свой специальный алгоритм, название этого метода везде делаешь одинаковое. В общем модуле обработки при переносе данных создаешь объект и дергаешь это экспортный метод

(15) >> Правильно понимаю что очень хочется Полиморфизм в 1С?

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

Задача в том, чтобы реализовать подобное поведение в 1С, и чтобы при этом не писать лишнего кода, и чтобы код получился "качественным" (то есть минимум ошибок, понятный, легко читаемый, расширяемый и т.д.).

>> Вроде как ВР доказывал что в 1С полноценное ООП ))

"ВР" - это кто?

ОбщегоНазначения.ОбщийМодуль(ИмяМодуляИнтеграцииБИП());

// Возвращает ссылку на общий модуль или модуль
// менеджера по имени.

не изобретай КД2 вновь...

+19

Подробности

Там просто так не сконвертируешь "РеквизитСтарый - РеквизитНовый". Там например из трех записей из старых БД собирается один новый контрагент.

т.е. ты не осилил и решил изобрести велосипед?

Маппинг_Модуль = ОбщегоНазначения.ОбщийМодуль("Маппинг_"+ИмяТаблицы);

(19) это уже КД3 у него

(21) Как получить ссылку на общий модуль - это я понял.

Как теперь передать "ИмяТаблицы" в глубину по цепочке всех вызовов всех методов, чтобы "ИмяТаблицы" было доступно в самом "глубоком" методе, которому нужно обратиться к модулю "Маппинг"?
Через параметры? То есть грубо говоря во всех методах будет один и тот же параметр - "ИмяТаблицы".

Правильно я понимаю?

(23) Как минимум. Логичнее чтобы в каждом методе был параметр "Параметры" типа структура, а там уже свойство "ИмяТаблицы" и пр.

КД2 писали с умом)

Генератор кода COM-обмена
https://infostart.ru/1c/tools/1281868/

(20),(22)
А разве в КД есть визуальное сопоставление с возможностью загрузки только проверенных и выбранных пользователем записей?

(26) загрузки нет, но есть отборы на стороне выгрузки

+27 а сопоставление в типовых есть

ахахаххаха люди придумали конвертацию)) писали выше но я чет угарел))

(27) отборы не нужны,
нужно:
1) гибкое сопоставление причем по разным признакам
(например, сначала ищем соответствие по "ИНН+КПП", если такое соответствие не найдено - ищем по "Наименование+ИНН", если не найдено - ищем "НаименованиеПолное+ИНН", если не найдено ... и т.д.),
2) визуальная проверка найденных соответствий, отметка флажком верных соответствий, отметка флажком подходящих к загрузке (некоторые записи могут сопоставиться правильно, но сведения у них неактуальные, таких не нужно загружать)

(28) >> а сопоставление в типовых есть

Cопоставление в типовых есть при синхронизации. В КД мне кажется нету сопоставления.

(30)
Всё, кроме визуальной части, есть в КД2.
Гибкое сопоставление, отмена загрузки в базе-приемнике, если "что-то".

Но вопрос то не в этом. Обработка уже есть.

Если обобщить, то вопрос в следующем.
В 1С есть общие "универсальные" модули, которые обращаются к другим общим "конкретным" модулям.
Как можно "подменить" вызовы этих "конкретных" модулей, чтобы при необходимости вызывались другие "конкретные" модули? Набор методов у "конкретных" модулей естественно одинаковый.

Как я понял, единственный способ - это передавать параметр типа "ИмяВызываемогоМодуля", а затем обращаться к этому модулю с помощью "Модуль = Вычислить(ИмяВызываемогоМодуля)".
Для того, чтобы этот механизм работал, надо во все методы "универсальных" общих модулей надо добавить параметр "ИмяВызываемогоМодуля".

Правильно?
Других способов нету?

Можно же через метаданные читать какие реквизиты есть у указанного справочника и собирать поля/табличные части на форме динамически. И общий модуль "Маппинг" сделать  универсальным для любого объекта.

Но может проще собрать свой пакет EnterpriseData и использовать КД3?

(0) Обрабатывать событие при выборе типа справочника на форме.А далее по предложенному в (13) способу.Он очень широко применяется разными разработчиками.Сколько справочников, столько твоих модулей - сам же пошёл по этому пути.Но существуют и более универсальные способы - через метаданные.