Интерфейсы в 1С #15
Comments
|
Я с идеей согласен, но этот механизм не является БСПшным - выставить публичный интерфейс (абстракцию) может кто угодно для любого механизма, который потом потребует имплементации в других объектах. Да, в БСП механизмы этим особенно часто пользуются... Но в ERP например тоже есть таки интерфейсы и реализации. |
|
В ЗУП тоже есть такие механизмы. Просто в БСП это явно в документации по внедрению написано, поэтому проще начинать разработку тому, кто не знает специфики ЗУП или ERP. |
|
А что если описывать не json/yaml, а где-нибудь хранить объекты-шаблоны, их и редактировать было бы проще уже имеющимися редакторами форм, модулей и т.п. , и, как мне кажется, реализовывать проверки на соблюдение будет проще |
|
В самой конфигурации наверное не хорошо, но почему бы и не создать подсистему для интерфейсов, каждая вложенная подсистема по названию интерфейса, а объекты, включенные во вложенную подсистему - контракт (реквизиты на формах, процедуры, реквизиты объектов, табличные части и т.д.) . Какие-то особенности можно вложить в префиксы/суффиксы объектов |
|
Еще одна из идей реализации интерфейсов:
name: МойВолшебныйИнтерфейс
baseType: СправочникМенеджер
methods:
Метод1:
returns: Строка
parameters:
- Параметр1:
type: Число
- Параметр2:
type: СправочникСсылка.Товары
- Параметр3:
type: Интерфейс.МойВторойИнтерфейсname: МойВторойИнтерфейс
baseType: УправляемаяФорма
attributes:
Атрибут1:
type: СправочникСсылка.Товары
...
// Параметры:
// ОбъектИнтерфейса - См. Интерфейс.МойВолшебныйИнтерфейс - тут в док коменте ссылка на интерфейс
// ОбъектИнтерфейса2 - См. Интерфейсы.МойВторойИнтерфейс
Процедура Тест(ОбъектИнтерфейса, ОбъектИнтерфейса2) Экспорт
ОбъектИнтерфейса.Метод1(12, Ссылка, ОбъектИнтерфейса2);
плагин будет генерит по описанию специфичные типы и загружать их в систему ЕДТ. Upd: не валидный, см. ниже |
|
Пример того как это может работать
Upd: не валидный, см. ниже |
1. Декларация интерфейсовМодель файлов описания интерфейса для модуля name: МойВолшебныйИнтерфейс.ВторичныйИнтерфейс # уникальное имя интерфейса с поддержкой name-space
# базовый/родительский тип к которому добавляются методы и свойства,
# может быть пустым - тогда тип самостоятельный
parentType: СправочникМенеджер
environments: # контроль доступности типа на Клиенте/Сервере
- SERVER
- THIN_CLIENT
methods: # поддерживается добавление методов, если в родительском типе их нет
Метод1:
returns: Строка # Возвращаемый тип, означает метод является функцией
export: true # признак что метод должен быть экспортным
parameters: # описание параметров метода
- Параметр1:
type: Число
- Параметр2:
type: СправочникСсылка.Товары
- Параметр3:
type: Интерфейс.МойВторойИнтерфейс
- Параметр4:
typeLink: ОбщегоНазначения.ФункцияКонструкторТипа # Любая ссылка на тип или объект, поддерживаемый в док.комментах
# Здесь возможно указать начальный шаблон заполнения текста метода при первом создании метода по имплементации
template: |
Если ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;Интерфейс для описания объекта метаданных
name: ИнтерфейсаОбъектаМД # уникальное имя интерфейса с поддержкой name-space
parentType: СправочникОбъект # базовый/родительский тип к которому добавляются методы и свойства
methods: # поддерживается добавление методов, если в родительском типе их нет
ПриЗаписи: # Возможно указывать метод, существующий в типе, описывать сигнатуру метода не нужно
# Выполняется поиск кода в тексте метода - валидация, что такой код существует в методе
containsCode: |
Свойства.ПриЗаписи(ЭтотОбъект, Отказ);
attributes: # возможность описания реквизитов объекта
МойРеквизит:
type: СправочникСсылка.Товары
tabularSections: # описание наличия таб.частей и их реквизитов
Товары:
attributes:
Товар:
type: СправочникСсылка.Товары
Количество:
type: Число(15,3)
Цена:
type: ОпределяемыйТип.Валютный
Сумма:
type: ОпределяемыйТип.Валютный
commands: # описание команд объекта
МояКоманда: # имя команды и далее свойства команды...Интерфейс для описания форм
name: КонтактнаяИнформация.ФормаКИ # уникальное имя интерфейса с поддержкой name-space
parentType: УправляемаяФорма # базовый/родительский тип к которому добавляются методы и свойства
methods: # поддерживается добавление методов в модуля формы, если в родительском типе их нет
Метод1:
returns: Строка # Возвращаемый тип, означает метод является функцией
export: true # признак что метод должен быть экспортным
pragma: AtClient # контроль прагмы для метода
parameters: # описание параметров метода
- Параметр1:
type: Число
- Параметр2:
...
attributes: # реквизиты формы
ИмяРеквизитаФормы:
type: ТаблицаЗначения
items: # элементы формы, которые должны присутствовать на форме
ДополнительнаяГруппаКИ
itemType: FormGroup2. Имплементация интерфейсовДля имплементации интерфейса у конкретного объекта можно сделать поддержку 2х режимов:
Например:
implements:
- КонтактнаяИнформация.ФормаКИ
- ИнтерфейсаОбъектаМД
// Заголовок модуля
// Копирайт модуля
// @strict-types
// @implements КонтактнаяИнформация.ФормаКИ, ИнтерфейсаОбъектаМД
Процедура ПриЗаписи()
...3. Использование интерфейсов в кодеВ документирующих комментариях станет возможным указывать типы интерфейсов и по-честному использовать их возможности.
// @strict-types
// Параметры:
// Фомра - КонтактнаяИнформация.ФормаКИ - тут честный тип обладающий свойствами/методами управляемой формы и дополнительным описанным в интерфейсе
Процедура ПриЗаписиВФорме(Форма) Экспорт
НоваяСтрока = Форма.ИмяРеквизитаФормы.Добавить(); // Обращение к реквизиту формы
...
Форма.Метод1(10); // Обращение к экспортным методам формы
// @strict-types
// Параметры:
// Фомра - Интерфейс.КонтактнаяИнформация.ФормаКИ - тут честный тип, но записывается с префиксом
// ПараметрыЗаписи - Структура
// Отказ - Булево
Процедура ПриЗаписиВФорме(Форма, ПараметрыЗаписи, Отказ) Экспорт
НоваяСтрока = Форма.ИмяРеквизитаФормы.Добавить(); // Обращение к реквизиту формы
...
Форма.Метод1(10); // Обращение к экспортным методам формыНеобходимо выбрать вариант предоставления типов. Плюсы и минусы? 3.2 Контроль вызова методов с интерфейсамиВ строгой типизации мы можем контролировать что параметры, передаваемые в метод - совпадают с имплементациями объекта: // Заголовок модуля
// Копирайт модуля
// @strict-types
// @implements КонтактнаяИнформация.ФормаКИ, ИнтерфейсаОбъектаМД
&НаСервере
Процедура ПриЗаписи(ПараметрыЗаписи, Отказ)
КонтактнаяИнформация.ПриЗаписиВФорме(ЭтотОбъект, ПараметрыЗаписи, Отказ);В этом примере все параметры проверяются на пересечение типов - т.к. "интерфейсы" теперь станут честными типами системы типизации ЕДТ - то так же будут проверяться по имплементации. 4. Доработки UI "интерфейсов"В навигаторе необходимо добавить:
5. Доработки ядра "интерфейсов"
|
@RedMammoth Хорошая идея, надо только продумать, как разделять вспомогательную часть свойств, которые нужны для демонстрации возможностей - от тех что нужно контролировать в реализации. И еще - это значит что будут мусорные объекты (формы, справочники, документы и т.д.) которые пойдут в рантам в ИБ. Это минус решения. |
|
@marmyshev есть пара комментариев к концепту #15 (comment)
|
Ваши рассуждения справедливы, но:
Согласен, что этот вопрос нужно тщательно рассмотреть отдельно. |
Да, нужно объяснение. С типом "ссылка" - рассуждения не верные. В 1С объект типа "модуль" не существует в полной мере (есть только тип "ОбщийМодуль") - но де-факто - передача модуля через параметры осуществляется очень-часто. Что это означает: что где-то в общем модуле есть код, которому на вход приходят различные "модули" у которых нужно вызывать методы. Коду всё равно какой именно модуль пришел (это общий модуль или модуль менеджера). Для таких случаев нужно описывать общий интерфейс модуля. Аналогичный пример с общими модулями - взять например подсистему БСП "Обновление ИБ" где необходимо создать общие модули "ОбновлениеИнформационнойБазыХХХ" для каждой подсистемы - в которой должна быть определенная сигнатура методов. Поэтому подменять "модуль" на "ссылку" - как-то совсем не правильно. Да, при этом по ссылке получать модуль - можно/нужно... но дальше мы передаем модуль куда-то и там с ним можно было бы работать как с интерфейсом. Отдельно стоит рассмотреть необходимость интерфейсов на "Ссылки" - нужны ли они? На самом деле - они уже есть в метаданных 1С - это "определяемые типы" в которых можно указать ссылки (ну как и другие типы объектов) - да, тут есть условность: что это не "интерфейс как нечто общее", а коллекция полных типов (имплементаций). Но всё же потребность их объединять есть. Наверное этот вопрос нужно детальнее исследовать. |
БСП содержит в себе механизмы, которые по сути требуют от подключенного объекта реализацию некоторого интерфейса. Например https://its.1c.ru/db/bsp314doc#content:4:1:issogl2_%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B037
То есть объект подключенный к механизму должен содержать внутри модулей некоторые методы и содержать в объектах некий набор табличных частей и реквизитов.
Пробовал на примере подсистемы Подключаемые команды сделать такие проверки:
https://github.com/DoublesunRUS/ru.capralow.dt.ssl.checks
В процессе реализации понял:
У меня сложилось мнение, что данную задачу можно решить через декларативное описание подобных интерфейсов.
Так как БСП не является открытой библиотекой, то в качестве декларативного описания нужно использовать внешний файл. Например json или yaml.
См. основной концепт
The text was updated successfully, but these errors were encountered: