При моделировании предметных областей довольно часто попадаются сущности двух видов:
(1) сущности, которые при изменении своего состояния (фактически при редактировании)
"перезатирают" свое предыдущее состояние
(2) и сущности, переходящие в новое состояние с сохранением информации о старом состоянии

И опять таки нередко бывает необходимость получать общее состояние моделируемой системы на заданный момент времени.


Вопрос: какие существуют достойные подходы или шаблоны к моделированию таких ситуаций?

Сразу возникает идея использования для (1) произвольных классов, а для сущностей (2) использовать иерархию базовых классов, производных от некотрого совсем базового класса Event со свойством — Time. В иерархию базовых классов для (2) могут быть войти классы, отвечающие за изменение-перезатирание какого-либо свойства EventRewriteValue, за применение какой либо операции к текущему значению свойства EventOperateValue и т.п.
Но чую, что существуют проверенные шаблоны. Также очень интересные решения по быстрому получению актуального состояния всех сущностей на заданный произвольный момент времени.

Спасибо!

Здравствуйте, sergunok, Вы писали:

S>(2) и сущности, переходящие в новое состояние с сохранением информации о старом состоянии
Можно пример?

Здравствуйте, rsn81, Вы писали:

R>Здравствуйте, sergunok, Вы писали:

S>>(2) и сущности, переходящие в новое состояние с сохранением информации о старом состоянии
R>Можно пример?

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

При этом присутствуют запросы: получить все кредитные продукты (со всеми их свойствами) на такой-то момент времени.

Здравствуйте, sergunok, Вы писали:

Может вынести эту автономную сущность в отдельный словарь: % ставка, время актуальности — и проблема уйдет сама собой. Или чего-то еще не учитываю?

PS Сам не сталкивался, но слышал про версионную поддержку в БД, может оно поможет?

Здравствуйте, sergunok, Вы писали:

S>При моделировании предметных областей довольно часто попадаются сущности двух видов:
S>(1) сущности, которые при изменении своего состояния (фактически при редактировании)
S>"перезатирают" свое предыдущее состояние
S>(2) и сущности, переходящие в новое состояние с сохранением информации о старом состоянии

S>И опять таки нередко бывает необходимость получать общее состояние моделируемой системы на заданный момент времени.


S>Вопрос: какие существуют достойные подходы или шаблоны к моделированию таких ситуаций?

S>Сразу возникает идея использования для (1) произвольных классов, а для сущностей (2) использовать иерархию базовых классов, производных от некотрого совсем базового класса Event со свойством — Time. В иерархию базовых классов для (2) могут быть войти классы, отвечающие за изменение-перезатирание какого-либо свойства EventRewriteValue, за применение какой либо операции к текущему значению свойства EventOperateValue и т.п.
S>Но чую, что существуют проверенные шаблоны. Также очень интересные решения по быстрому получению актуального состояния всех сущностей на заданный произвольный момент времени.

Паттерн Посетитель

Автор(ы): Андрей Корявченко
Дата: 06.12.2006
Очень часто в программах встречаются сложные структуры, представляющие собой дерево или граф, состоящий из разнотипных узлов. И, конечно же, при этом имеется необходимость обрабатывать этот граф. Самое очевидное решение — добавить в базовый класс виртуальный метод, который перекрыть в наследниках для выполнения нужного действия и осуществления дальнейшей навигации по дереву.
Однако у этого приема есть серьезный недостаток: в нем структура данных оказывается увязанной с обрабатывающими ее алгоритмами. Если нам понадобится алгоритм, отличный от реализованного, то придется добавлять еще один виртуальный метод. Еще хуже, если классы, составляющие дерево, содержатся в недоступном для модификации коде.
Одним из вариантов решения проблемы высокой связности в данном случае является паттерн Посетитель.

?

Основная идея этого паттерна состоит в том, что каждый элемент объектной структуры содержит метод Accept, который принимает на вход в качестве аргумента специальный объект, Посетитель, реализующий заранее известный интерфейс. Этот интерфейс содержит по одному методу Visit для каждого типа узла. Метод Accept в каждом узле должен вызывать методы Visit для осуществления навигации по структуре

Здравствуйте, sergunok, Вы писали:

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

Давно известная ссылка не подойдет?