Валерий Крылов (justy_tylor) wrote,
Валерий Крылов
justy_tylor

Category:
  • Music:

точки зрения и 4D

1. История

Несколько лет назад я был очарован архитектурой Alias Maya (ныне Autodesk Maya). Идеальных редакторов нет, и частные решения были где-то лучше в Maya, где-то лучше в 3ds Max, где-то в других продуктах. Но один момент зацепил очень сильно.

При обработке сложных структур данных в ОО языках со статической типизацией (C++, Java, C#, ...) часто появляются ситуации, когда есть несколько интерфейсов работы с объектом, причём их доступность может быть определена только в runtime. Типичное решение:
MyInterface* interface = node->GetMyInterface();
if(interface) interface->DoSomething();
Решение в стиле Maya:
MObject node = objects[0];
MFnDAGNode dag_node(node);
MBoundingBox box = dag_node.boundingBox();
Теперь node может быть чем угодно, не указателем, а любым идентификатором, скрытым в MObject. Более того, в Maya есть способ спросить MObject о поддержке какого-либо стандартного MFn*, но ничего не мешает сделать свой MFnMyInterface, о котором MObject не знает, но который сам знает, операции с какими из MObject он поддерживает.

Далее я много работал с языками и нотациями. Знакомство с Gellish и ORM (Object Role Modelling) привело к мысли, что разделение identity какой-либо сущности и её свойств может быть очень полезным в общем случае. Негибкий комплект object+attributes создаёт слишком много проблем.

А чтение http://plato.stanford.edu/entries/temporal-parts/ привело к следующей. Любые свойства сущности зависят от точки зрения. Вчера была глина, сегодня она превратилась в скульптуру. У нас есть разные точки зрения, для вчера и сегодня. Вопрос идентичности той глины и сегодняшней скульптуры это только наш выбор.

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

Сейчас я немного вернулся к теме редакторов и их представления информации. Это возвращение породило новый дизайн.

2. Решение

Все (пока "все редактируемые", дальше не забираюсь) сущности в системе представлены каким-то уникальным набором identity. Они относятся к типу ID, который может быть:

1) Уникальным целым числом.
2) Указателем на некую структуру в памяти.
3) GUID.
4) Индексом для базы данных.
5) Чем угодно. Важна только уникальность.

А доступ к чтению или изменению любых свойств этих сущностей возможен только через контексты, точки зрения.

Представим ситуацию с редактором, в котором открыта 3D сцена с анимацией. В сцене есть некий автомобиль, и в рассматриваемом коде он уже доступен через переменную car. Так может выглядеть получение свойства position этого автомобиля в традиционных решениях:
car.position()
// (0, 0, 10)
Достаточно просто. Но ведь у нас есть ещё и анимация. И если нужна позиция машинки в какой-то момент времени, то либо придётся вручную дотягиваться до треков анимации и доставать её оттуда, либо глобально запускать анимацию на всю сцену, проматывать её, а уже потом брать car.position(). Слишком грубо. Но если работать со свойствами-в-контексте, то можно проще:
document (car).position()
// (0, 0, 10)

animator = document.makeanimator()
animator.select("moving_animation1")
animator.def_time(14)

animator (car).position()
// (75.10, 12.43, 10)
document (car).position()
// (0, 0, 10)
animator.time(15) (car).position()
// (76.34, 9.07, 10)

Более того, в анимации могут легко создаваться новые сущности или меняться существующая иерархия сцены, не затрагивая статичное состояние сцены в документе:
document (car).parent()
// id131
animator (car).parent()
// id258
И вот, у нас есть контекст документа и контекст анимация+время. История изменений документа - тоже хороший контекст. Что ещё является контекстами? Точка зрения... point of view. И наши вьюхи для документов это тоже контексты.
view1 (car).uibox_color()
// "red"
view2 (car).uibox_color()
// "purple"
view1 (car).uibox_color("green")
view1 (car).uibox_color()
// "green"
view2 (car).uibox_color()
// "purple"
Вместо дублирования данных получаем добавление свойств-в-контексте к готовым identity, что намного проще для обработки и синхронизации.

Разумеется, хранение свойств-в-контексте может быть чуть более затратным но для языков с динамической типизацией или структур типа Dependency Graph в Maya это почти незаметно. А выигрыш от не-дублирования информации может наоборот привести к повышению скоростных характеристик кода.

Для обработки сложной информации с разных точек зрения - включая 4D (рекомендуемое чтение: http://tedsider.org/papers/4d.pdf) - такое архитектурное решение оказывается наиболее удобным. И просто красивым. :)
Subscribe

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 4 comments