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