А.С.Дружинин

Живые и мертвые, или объектами не рождаются

Речь, как Вы догадываетесь, пойдет отнюдь не о кадаврах и франкенштейнах, а об объектах. Разделение на "живые" и "мертвые" тоже в достаточной степени условно, и носит нейтральный характер:

• "Живой" - это объект с собственными методами (поведением)
• "Мертвый" - тоже объект, но как бы пассивный - у него все есть, но работают за него другие, извлекая из него его свойства.

В некотором смысле существующие объекты БД в qWORD - мертвые. Да, и собственно, объектов БД, как таковых, кот наплакал - записи да атрибуты. Вот интерфейсные объекты уже поживее, у них есть что-то индивидуальное в том смысле, что их поведение может меняться в зависимости от ситуации (возникающих событий). А почему, собственно информационные объекты должны быть мертвыми или полумертвыми? Ответом на этот вызов времени послужила концепция виртуального документа. Оный виртуальный документ состоит из двух частей:

1. "Матрицы" (описателя свойств документа) - индивидуализированая часть
2. "Оживлятора" - интерпретатора этого описателя - вот он пока стандартен для всех типов виртуальных документов

Сам по себе виртуальный документ до поры до времени пребывает в зародышевом состоянии, в виде набора свойств (возможно и неполного). Как только приходит пора, окончательно определяют недостающие свойства, и запускают процесс репликации, в ходе которого в соответствии с описанием порождаются экземпляры виртуального документа. В ходе этого процесса могут порождаться как реальные экземпляры документов, так и описания новых виртуальных документов, к которым может применяться ровно такой же процесс. Вот, собственно, и все. В принципе, ровно этот подход уже применен в qWORD'е к интерфейсным объектам. Давайте расширим это вообще на объекты всех типов.

С чего можно начать? Вспомним, что база данных, вернее один из основных способов работы с ней - это навигация. В самом общем смысле навигация предполагает наличие некоторой упорядоченности, когда находясь в каком-то текущем состоянии (пока определяемом исключительно кодом записи), мы твердо знаем, какое состояние - следующее, какое - предыдущее. Более того, для этого в базовом qWORD'е есть даже функции. На самом деле ситуация абсолютно общая, и не зависит от записей и прочей конкретики. Ее можно трактовать следующим образом:

1. Имеется некоторый параметр, однозначно характеризующий состояние объекта. Этот параметр, в принципе, может иметь сколь угодно сложную структуру, и не сводиться к строке символов. Более того, он может быть и активным, т.е. включать в себя кроме декларативной и процедурную часть. Удобно рассматривать сам этот параметр как некоторый объект, который так и назовем "Параметр".
2. Имеется некоторая функция от этого параметра, или, в другой интерпретации, объект "Параметр" имеет метод. Применение этой функции (метода) к текущему параметру (объекту) и дает нам следующее(предыдущее) значение параметра (экземпляр объекта, а если быть точным, ссылку на экземпляр объекта).

Представляется, что в эту схему можно единообразным способом уложить довольно много. Почему? Вспомним стандартный цикл:

1. Отбор объектов данных, участвующий в порождении новых объектов данных
2. Применение к совокупности отобранных объектов "виртуального" документа

Первый пункт этого цикла сейчас реализуется с помощью объекта-фильтра, в коем мы задаем какие-то условия. или ручками помечаем то, что нам нужно, затем уточням (применяем следующий фильтр), и т.п. до победного конца. Сейчас есть две базисных конструкции - функция-фильтр (в некотором смысле виртуальный документ) и статические данные - список релевантных. К сожалению, рекурсивное применение "виртуального документа" ограничивается одной-единственной итерацией, т.е. сначала надо полностью породить список релевантных (пассивные данные), и только затем применить к нему метод порождения следующего списка релевантных (который по смыслу отвечает реализации набора экземпляров уже другого объекта!). Пока статические компоненты "малы", все фурычит быстро, но стоит им сделаться большими, как дело замедляется минимум в два раза - мы сначала выбираем все (порождаем совокупность ссылок), а затем перебираем ее еще раз при использовании атрибутов этих записей. Представляется целесообразным наряду с таким статическим способом иметь и полностью динамический, когда мы уточняем не список ссылок, а свойства объекта, который при своем "оживлении" породит нам оный. В некотором смысле это более правильно, поскольку в первом случае мы неизбежно будем терзаться сомнениями - а вдруг за то время, как мы порождаем этот статический список, некоторые  объекты из этого списка исчезнут, или, хуже того, так изменят свои свойства, что, продолжая существовать, уже не будут релевантными. В таком аспекте "динамический" объект гораздо лучше. Например, хотя бы по той причине, что не нужно порождать дополнительные структуры данных в виде глобала, а иметь просто один объект- ссылку на текущий экземпляр, определяемый объектом "Параметр". Кстати, во всех скролловых интерфейсных элементах реализован ровно это подход. Почему не применить его и к чисто информационным объектам?

Ровно такая конструкция применена для динамического порождения HTML-кода. (Достаточно очевидно, что специфика, связанная с  HTML-кодом, упрятана в одну-единственную переопределяемую функцию - как интерпретировать полученные данные, т.е. имена ссылок). Вся разница между статическими и динамическими данными состоит в том, что   применяется другая функция Next(parm), ссылка на которую содержится в описателе объекта. Если данные (список ссылок) есть, и статичны, то применяется просто $O по ним, если же данные "динамичны" - изволь предоставить соответствующую функцию (метод). И все работает, как и задумывалось.