Объекты платформы 1С:Предприятие 8 нельзя рассматривать как классический пример ООП, скорее это объектное представление записей таблиц базы данных. Поэтому при разработке приложений часто возникают задачи, свойственные именно разработке БД
- изменить значение одного поля таблицы
- добавить новую строку подчиненной таблицы
Для примера рассмотрим простой объект, который использует для хранения 2 таблицы БД:
Для данного объекта определены следующие зависимости:
- получение цены номенклатуры в зависимости от даты и клиента
- Сумма в строке = Цена * Количество
- Цена = Сумма в строке / Количество
- Сумма = Итог("Сумма в строке")
При этом нужно учитывать, изменение номенклатуры вызывает цепочку таких зависимостей, поэтому простые модели зависимостей (например с помощью триггеров БД) в данном случае не подходят
Было бы удобно описать все эти зависимости в одном месте, а затем для модификации объекта использовать понятный интерфейс для доступа к данным, например:
Для Каждого СтрокаОснования Из Основание.Товары Цикл
НоваяСтрока = НовыйДокумент.Товары.Добавить();
НоваяСтрока.Номенклатура = Основание.Номенклатура;
НоваяСтрока.Количество = Основание.Количество;
КонецЦикла;С помощью подсистемы Модель объекта можно реализовать подобную модель работы с данными на платформе 1С:Предприятие 8
В будущем Заказ клиента может стать гораздо сложнее, у него могут появиться новые табличные части, дополнительные колонки, но данный алгоритм все равно продолжит работать.
При разработке информационной системы, могут создаваться десятки объектов метаданных типа Документ. При этом разработчики стараются унифицировать имена таблиц и реквизитов, чтобы по-максимуму использовать обобщенные алгоритмы при работе с данными. Например мы можем добавить объект:
Для данного объекта определены следующие зависимости:
- Сумма в строке = Цена * Количество
- Цена = Сумма в строке / Количество
- Сумма = Итог("Сумма в строке")
Можно заметить, что часть зависимостей является общими с документом "Заказ клиента". При использовании подсистемы Модель объекта можно общие зависимости определить в общем модуле, и использовать их из обоих документов. Подобный подход может быть аналогом наследования и полиморфизма, типичных для классического ООП.