Дмитрий Малюгин где-то в 2001 Размышления о наследовании свойств объектов, об абстрактных справочниках и документах, об
объектах неопределенного типа наводят на мысль об использовании в платформе такого
семантического понятия как Роль.
Что такое роль? По сути это совокупность каких-либо качеств объекта, которые
проявляются при его взаимодействии с другими объектами. Если такого взаимодействия нет
(еще не было), то и качеств тоже нет (пока нет). Похоже, что реквизиты агрегатных объектов
должны ссылаться на другие агрегатные объекты не непосредственно, а через роли.
Соответственно, роль это и не справочник, и не документ, но исполнять ее
должны элементы справочников или документы. Задание справочника в качестве возможного
исполнителя какой-либо роли определяет, что на элементы данного справочника могут ссылаться
те объекты агрегатного типа, среди реквизитов которых есть данная роль.
Пример. В расходной накладной реквизит "Покупатель" это обычно ссылка
на справочник "Контрагенты". Гораздо гибче было бы, если бы данный реквизит ссылался
не непосредственно на справочник "Контрагенты", а через роль "Покупатель".
В качестве же "Покупателя" могут выступать как "Контрагенты", так и
"Физические лица", "Сотрудники". Соответственно, и в регистре
"Оборот продаж" измерение "Клиент" тоже должно ссылаться не на справочник,
а на роль "Покупатель".
В V7 для того, чтобы продать товар "неконтрагенту", надо либо объявить реквизит документа
"покупатель" абстрактным справочником, либо в справочнике "Контрагенты" заводить
новый элемент и как-то организовывать его связь с "неконтрагентом". И то, и другое не очень
удобно.
Роль является объектом агрегатного типа. Она должна иметь перечень объектов-исполнителей
роли и может иметь свои реквизиты. Если справочник (документ) допускает использование
непосредственных ссылок на свои элементы, значит сам справочник задает также наименование
и реквизиты роли, которую исполняют его элементы. Например, справочник "Сотрудники"
определяет одноименную роль.
Введение ролей намного ослабит потребность в механизме наследования свойств у справочников.
Рассмотрим последовательно применение обоих подходов (наследование свойств и роли) к
отражению в конфигурации того факта, что продавать можно не только товары, но и материалы,
ценные бумаги, основные средства и т.д. Все перечисленное отдельные справочники,
поскольку каждый имеет свой особенный перечень свойств. Надо сделать так, чтобы иметь
возможность указывать в расходной накладной (и, соответственно, в регистрах реализации)
в качестве товара элемент любого из этих справочников.
С точки зрения наследования необходимо сделать следующее. Завести абстрактный справочник
"Номенклатура" и наследовать от него перечисленные выше. Реквизит накладной
"Товар" должен ссылаться на справочник "Номенклатура", так что теперь
любой справочник, принадлежащий "Номенклатуре", может быть выбран в накладной в
качестве товара. С точки зрения ролей все еще проще. Реквизит накладной "Товар"
ссылается на роль "Товар для продажи". А исполнителями данной роли (помимо
"самих товаров") являются справочники "Материалы", "Ценные бумаги",
"Основные средства" и т.д.
Если при наследовании желательно продумать иерархию классов заранее, до начало эксплуатации
программы (что не всегда возможно сделать), то "при ролях" в этом нет необходимости.
В любой момент можно к введенной роли добавить дополнительного исполнителя. Пусть на этапе
конфигурирования мы "забыли", что основные средства могут служить объектом продажи.
Добавление в конфигураторе справочника ОС к исполнителям роли "Товар" не влечет
никаких изменений в информационном наполнении БД. ОС просто становятся "потенциальным
товаром", после чего у пользователя появляется возможность указать для каждого конкретного
ОС, что данное ОС это и товар одновременно. В результате к реквизитам ОС добавляются
реквизиты ОС в роли "товар".
Понятие "Роль" увеличивают нормализацию базы данных за счет отделения атрибутов
непосредственно объекта (как сущности) от атрибутов ролей, которые он может исполнять
(а может и не исполнять) нормализация атрибутов. До тех пор, пока ОС не
выступит в роли товара, никаких записей со значениями "товарных" реквизитов данного ОС в
ТД "Товары" не будет.
Роль могут исполнять объекты разных типов (справочники, документы). Например, роль
"Партия товара". Исполняется документами "Приходная накладная",
"Приходная счет-фактура". Реквизиты роли характеристики партии.
Во многих примерах "наследование свойств классов" на самом деле можно (нужно) заменить
"ролями класса". Проверка на "истинное наследование" это тест на справедливость
утверждения "всегда является" (собака всегда является животным). Если же справедливо
"может являться (быть)" то это роль (сырье может быть товаром).
Резюме.
- Понятие "Роль" выглядит перспективным направлением в плане развития V7,
но нуждается в дополнительном изучении. Преимущества использования понятия очевидны, но
детали программной реализации требуют тщательного продумывания.
|