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

Частица и квазичастица, или как объять необъятное.

Не добраться до тебя,
Эдак ты укутана.
В этом мире все с собой
Взаимно перепутано.
А.Зиновьев, Философские частушки

Реальность такова, что нет никакой возможность ни понять ее полностью, ни детально управлять ею. Одно влечет за собой другое, и нет надежды найти "начало того конца, которым оканчивается начало" (К. Прутков, Афоризмы). Однако все и вся как-то выкручиваются. Как выкручиваются? А очень просто, вместо реальности со всеми ее сложными взаимосвязями строят некоторую модель. Модель, естественно, неполная, но если она отражает какие-то существенные черты моделируемого объекта, есть надежда успеть разобраться с ним и его поведением за такой промежуток времени, в течение которого можно убить двух зайцев:

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

Представляется, что именно так и поступают все, кто достигает успеха. Посмотрим, как это делают, например, физики в сложных ситуациях. Возьмем, например плазму - газ заряженных частиц. Она состит из легких отрицательно заряженных электронов и тяжелых положительно заряженных ионов. И тех, и других, очень много (10**18/см3), и они очень сильно между собой взаимодействуют, и нет никакой надежды написать систему уравнений, описывающей поведение этого объекта. Вернее, уравнения-то написать можно, а вот решить нельзя. Как поступили хитрецы-физики в этой и других подобных ситуациях (например, в случае взаимодействия электронного газа с кристаллической решеткой). А они ввели понятие квазичастицы, т.е. объявили какую-то совокупность электронов и ионов одной сущностью(выделили некоторую подсистему), в первом приближении пренебрегли взаимодействием между объектами, входящими в разные подсистемы, аккуратненько разобрались с подсистемой как таковой, и выяснилось, что вместо большого количества сильно взаимодействующих объектов(электронов и ионов) имеется существенно меньшее количество слабо взаимодействующих объектов(квазичастиц). Конечно, при этом произошла некоторая потеря информации (которая, впрочем, была абсолютно недоступна - не было способа ее извлечь), но зато мы получили хоть какую-то информацию о поведении объекта, которая тут же может быть использована для более детального описания поведения более мелких структурных сущностей(электронов и ионов), входящих в каждый из объектов более высокого уровня (квазичастиц). Во многих случая нам и не нужны детали нижнего уровня (инкапсуляция).

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

Да, ответим мы, должен быть учтен. Но зачем все сразу? Тратя силы (память и процессорное время), не забываем ли мы, что конечный-то результат - не учет всех винтиков и гаечек, а нечто реально работающее, причем конечная цель этой работы скрыта от программы. Откуда ей знать, что мы будем делать с полученным результатом - сразу выбросим в корзину, грязно ругаясь, или торжественно понесем распечатку вышнему начальству, дабы заслужить снисходительную похвалу оного "ну наконец-то, взялись за ум!". А на пути к конечному результату мы порождали множество временных структур, сами, может быть, и не подозревая о том. У нас была цель - добраться до противоположного берега реки во время ледохода, вот мы и прыгали с льдины на льдину, заботясь не о том, чтобы обустроить каждую льдинку, а лишь используя ее как точку опоры для очередного шага.

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

Ясно, если есть какая-то структура данных, то есть и методы работы с ней. Методов - с гулькин нос:

1. Работа с записями:
   1. Создать запись (вырастить веточку, сучок)
   2. Уничтожить запись (срубить)
   3. Найти записи, удовлетворяющие каким-то условиям
   4. Узнать отца данной записи
2. Работа с атрибутами
   1. Узнать значение атрибута
   2. Изменить значение атрибута записи
   3. Уничтожить значение атрибута записи

Вот, собственно, и все методы работы с "пассивными" сущностями. Все остальные - производные от них, образуются той или иной комбинацией этих базисных. У нас есть, однако, и "активные" сущности - информационные и интерфейсные объекты, свойства которых могут быть разложены ровно в такую структуру данных. Что нам осталось? Самая малость:

1. Возможность объявить какую-то последовательность элементарных методов новым методом, и меть возможность его исполнить.
2. Пополнить набор методов, рассматривая только что порожденный метод как атомарный.
3. Выполнить метод

Что с этой точки зрения любая программа(метод) - документ со следующими свойствами:

1. Имя метода - запись
2. Параметры метода - атрибуты записи

Что он(метод) делает - создает (или изменяет) записи и значения их атрибутов. Метод-запись обладает одним существенно новым свойством - он "беременен" новыми записями (документами), но до поры до времени не явит их на свет божий. Для того, чтобы их (потенциально существующие записи) перевести из виртуального состояния в реальное надо дать команду - выполнить. Круг замкнулся - нам не надо привлекать никаких дополнительных структур данных и способов работы с ними. Осталась, конечно, самая малость - а кто выполняет эти методы, кто, как и где хранит эти записи. А мы смело скажем - это не наше дело, сегодня - qWORD, завтра еще что-нибудь. Нам-то от этого экзекутора-интерпретатора почти ничего и не надо, лишь бы умел делать то немногое, что описано выше, а дальше раскруткой получается все, что нужно.

Вот и все. Осталось проследить, как эта простенькая схема претворяется в жизнь.А претворяется она очень и очень просто:

1. Моделируем предметную область с помощью этих структур и этих методов. Здесь есть некоторая разница - не надо привлекать новых структур, но вполне допустимо создавать новые методы работы с ними на основе имеющихся. Правда, надо крепко подумать, насколько нужен этот новый метод, а нельзя ли обойтись только имеющимися.
2. Некоторые записи у нас будут конечными данными (реальный документ), а некоторые - описанием способа получения других записей (виртуальный документ). Разница не слишком большая, но все дело в том, что некоторые данные мы получаем извне (внешний ввод), а некоторые порождаем программным путем, причем обоих видов - и конечные данные, и метаданные - описатели способов порождения других данных.

Стандартный цикл работы получается очень и очень простой:

1. Тем или иным способом отбираем записи, на основании которых мы хотим породить новые записи (объект - фильтр). В обыденной терминологии- список релевантных (на самом деле это гораздо более общая вещь, чем просто массив ^QR). В процессе этого отбора нам, возможно потребуется многократно выполнить п.2, но это не страшно.
2. Применяем к совокупности отобранных записей какой-то метод, и порождаем новую совокупность записей. Вполне вероятно, что при порождении новых записей нам придется многократно применять п.1, но это не страшно.
3. Повторяем цикл

Прелесть этого цикла в том, что он очень легко формализуем, и требует для своей реализации очень ограниченного количества методов и одной-единственной структуры данных!

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

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

Еще одно преимущество - можно объять необъятное, но не сразу, а за несколько этапов. Если на каждом шаге для порождения новых записей мы используем не абсолютно всю информацию, доступную нам, и порождаем не абсолютно все сразу, то процесс будет состоять из конечного количества вполне обозримых шагов, причем многие могут порождаться совершенно автоматически - например, оформление накладной на отпуск товара может вызвать целую цепочку создания документов о внутреннем перемещении, осуществления проводок, и т.п. Главное, что не надо сразу пытаться сделать все и учесть все тонкости, а по этапу, по этапчику - и за сорок лет доползем до мыса Дежнева! Не напоминает ли это вам, господа qWORDисты, действия по изменениям и псевдособытия? Должно напоминать, ибо так и должно быть - какие-то прикладные методы должны мигрировать в сам инструмент, и наоборот.

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