Использование «Контрактов» в «1С:Предприятие.Элемент»

Продолжая знакомиться с возможностями технологии «1С:Предприятие.Элемент» нельзя обойти стороной новый для разработчиков на «1С:Предприятие 8» механизм контрактов.

Понятие «контрактное программирование» активно применяется в разных языках и платформах. В «1С:Предприятие.Элемент» разработчики добавили возможность взаимодействия с контрактами через прикладные объекты и встроенный язык программирования. Добавили 3 типа объектов, которые можно использовать для разных целей и задач. В материале рассмотрим новый механизм вместе с примерами применения этих объектов при разработке/проектировании приложений.

Что такое контракты?

Контракт – это набор правил, договоренность между разработчиками по поводу наличия определенных полей/функциональности у объекта. Чтобы избежать ошибок в языках программирования, обычно применяются особенные синтаксические конструкции/объекты для работы с контрактами. А среда разработки/компилятор контролирует, что разработчики действительно соблюдают «договоренности».

Контракты помогают программистам понять, что нужно ожидать от определённой функции или модуля. Это упрощает чтение и поддержку кода.

При разработке приложений в больших командах контракты позволяют разрабатывать разные части системы независимо друг от друга, так как разработчики могут полагаться на чёткие соглашения без необходимости знать детали реализации внутри модуля/объекта.

В «1С:Предприятие.Элемент» для работы с контрактами добавлены следующие объекты:

Контракт типа

Контракт типа – позволяет указать соглашения, которые сможет реализовывать какой-либо тип. В нем можно «договориться» на наличие определенных методов или полей.

Рисунок 1 – Пример контракта типа

Например, создадим контракт типа «ФормаСШапкой», где опишем абстрактный метод «ЗаполнитьШапку» и укажем у контракта поле «ЗаголовокШапки». Важно помнить, что это ещё не сама форма, а только описание того, что мы ждем от типов, реализующих этот контракт.

Далее создадим совершенно пустую форму и укажем в свойстве «НастройкаТипа» созданный контракт «ТипФормаСШапкой».

Рисунок 2 – Панель свойств формы, реализующей контракт

Появятся ошибки, которые мы ожидали. Элемент попросит реализовать абстрактный метод «ЗаполнитьШапку» и не пустит дальше, пока мы не переопределим в нашем типе свойство, о наличии которого «договорились» при создании контракта.

Рисунок 3 - Пример ошибок при несоблюдении контракта

Мы обязуемся реализовать контракт полностью. Среда Разработки будет выдавать ошибки, пока в типе «МояФорма» не будут полностью описаны все абстрактные методы и свойства из контракта. Важно помнить, что все директивы должны быть идентичны контракту, например, область видимости в контракте и реализации так же должны совпадать.

Контракт сущности

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

Хорошей иллюстрацией таких контрактов сущности является определенный справочник.

Например, контракт сущности «СущностьЖивотное», а его реализации «Собака, «Кошка» и «Жираф». В программном коде мы сможем обратиться к типу СущностьЖивотное.Ссылка таким же образом, как к «реальным» справочникам. «Контракт сущности» помимо одноименного типа так же порождает тип «СущностьЖивотное.Ссылка».

Использование контрактов в качестве определяемого типа

Рассмотрим пример того, как контракт можно использовать как аналог функциональности «Определяемых типов» из «1С:Предприятие 8».

Рисунок 4 – Пример применение контракта типа в качестве определяемых типов

Код выше корректен в случае, если у справочников «Пользователь», «Контрагент» и «Робот» указать в свойстве «Настройки типа» контракт «ИсполнительСущность».

В данном случае мы не обязуемся реализовать какие-то методы или описать поля, однако применение «Контрактов сущности» в таком ключе тоже оправдано, так как позволяет:

1. Сократить код, например, в директиве метода пришлось бы указывать все ожидаемые типы: Множество<Пользователь.Ссылка|Контрагент.Ссылка|Робот.Ссылка?>;

2. Обратиться через запрос ко всем таблицам типов, реализующим контракт сущности;

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

Контракт сервиса

Контракт сервиса создан для работы только с типами-одиночками.

Рисунок 5 – Пример модуля «Контракта сервиса»

Например, реализациями такого контракта может быть как общий модуль, так и модуль какого-нибудь справочника. Касательно работы с абстрактными методами функциональность идентична контрактам «Сущности и Типа», но всё же имеет несколько особенностей.

Рисунок 6 – Свойства типа «Контракт сервиса»

У контракта есть 2 уникальных свойства:

«Обязательный» – если Истина, будет выдавать ошибку при отсутствии в проекте типов, реализующих контракт.

«Множественный» – если Ложь, то Среда Разработки будет выдавать ошибку, когда реализаций контракта больше одной. Это полезно, если мы используем «Контракт сервиса» в качестве интерфейса для какого-либо механизма, чтобы скрыть от программиста лишнюю реализацию.

Рисунок 7 – Ошибка «Контракта сервиса» при отсутствии реализаций

Почему стоит начать использовать Контракты

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

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