• Начало

• Hare.ru @ дикое место
  • Лирика
  • Политика
  • Хай-тек
  • Синема
  • Лирика 2
• Hare.ru @ коллективный разум
  • Бухгалтерия и прочий учёт
  • Концептуальные работы
  • Полезные технологии
  • Собственные руки TM
• О проекте
• Информация
  • Реклама
  • Телеканал Россия 1 на компьютере

Концептуальные работы

Все статьи раздела

От V7 к V8. Обсуждение концепций структур данных. Роли объектов и наследование.

Дмитрий Малюгин (где-то в 2001)

Что такое роль? По сути – это совокупность каких-либо качеств объекта, которые проявляются при его взаимодействии с другими объектами. Если такого взаимодействия нет (еще не было), то и качеств тоже нет (пока нет). Похоже, что реквизиты агрегатных объектов должны ссылаться на другие агрегатные объекты не непосредственно, а через роли.

Соответственно, роль – это и не справочник, и не документ, но исполнять ее должны элементы справочников или документы. Задание справочника в качестве возможного исполнителя какой-либо роли определяет, что на элементы данного справочника могут ссылаться те объекты агрегатного типа, среди реквизитов которых есть данная роль.

Пример. В расходной накладной реквизит "Покупатель" – это обычно ссылка на справочник "Контрагенты". Гораздо гибче было бы, если бы данный реквизит ссылался не непосредственно на справочник "Контрагенты", а через роль "Покупатель". В качестве же "Покупателя" могут выступать как "Контрагенты", так и "Физические лица", "Сотрудники". Соответственно, и в регистре "Оборот продаж" измерение "Клиент" тоже должно ссылаться не на справочник, а на роль "Покупатель".

В V7 для того, чтобы продать товар "неконтрагенту", надо либо объявить реквизит документа "покупатель" абстрактным справочником, либо в справочнике "Контрагенты" заводить новый элемент и как-то организовывать его связь с "неконтрагентом". И то, и другое не очень удобно.

Роль является объектом агрегатного типа. Она должна иметь перечень объектов-исполнителей роли и может иметь свои реквизиты. Если справочник (документ) допускает использование непосредственных ссылок на свои элементы, значит сам справочник задает также наименование и реквизиты роли, которую исполняют его элементы. Например, справочник "Сотрудники" определяет одноименную роль.

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

С точки зрения наследования необходимо сделать следующее. Завести абстрактный справочник "Номенклатура" и наследовать от него перечисленные выше. Реквизит накладной "Товар" должен ссылаться на справочник "Номенклатура", так что теперь любой справочник, принадлежащий "Номенклатуре", может быть выбран в накладной в качестве товара. С точки зрения ролей все еще проще. Реквизит накладной "Товар" ссылается на роль "Товар для продажи". А исполнителями данной роли (помимо "самих товаров") являются справочники "Материалы", "Ценные бумаги", "Основные средства" и т.д.

Если при наследовании желательно продумать иерархию классов заранее, до начало эксплуатации программы (что не всегда возможно сделать), то "при ролях" в этом нет необходимости. В любой момент можно к введенной роли добавить дополнительного исполнителя. Пусть на этапе конфигурирования мы "забыли", что основные средства могут служить объектом продажи. Добавление в конфигураторе справочника ОС к исполнителям роли "Товар" не влечет никаких изменений в информационном наполнении БД. ОС просто становятся "потенциальным товаром", после чего у пользователя появляется возможность указать для каждого конкретного ОС, что данное ОС это и товар одновременно. В результате к реквизитам ОС добавляются реквизиты ОС в роли "товар".

Понятие "Роль" увеличивают нормализацию базы данных за счет отделения атрибутов непосредственно объекта (как сущности) от атрибутов ролей, которые он может исполнять (а может и не исполнять) – нормализация атрибутов. До тех пор, пока ОС не выступит в роли товара, никаких записей со значениями "товарных" реквизитов данного ОС в ТД "Товары" не будет.

Роль могут исполнять объекты разных типов (справочники, документы). Например, роль "Партия товара". Исполняется документами "Приходная накладная", "Приходная счет-фактура". Реквизиты роли – характеристики партии.

Во многих примерах "наследование свойств классов" на самом деле можно (нужно) заменить "ролями класса". Проверка на "истинное наследование" – это тест на справедливость утверждения "всегда является" (собака всегда является животным). Если же справедливо "может являться (быть)" – то это роль (сырье может быть товаром).

Резюме.

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

Партнеры: