Динамическое формирование объектов
При разработке программ часто возникает необходимость модифицировать уже существующие базовые классы объектов: добавлять в них новые данные и методы, перекрывать уже существующие.
Предположим, у нас есть класс line, объекты которого представляют линии в пространстве или на плоскости. Такой класс может содержать информацию о геометрии линии в виде массива узлов (отрезков) или метода их порождения. В какой-то момент появляется задача вывода линий на экран. Причём для каждой линии пользователь может задать цвет, которым она будет рисоваться во всех окнах. Этот цвет должен сохраняться-загружаться, импортироваться - экспортироваться вместе с самой линией вплоть до самого её удаления.
Естественное решение - добавить в класс line переменную color, а в методы, сохраняющие и загружающие объекты класса - запись и чтение её значения. Через некоторое время пользователю может понадобиться, чтобы цвет узлов линии задавался отдельно, и мы добавим в класс ещё одну переменную - <цвет узла>. Затем добавится возможность выделять отдельные участки линии и появится <цвет выделенного участка>, <цвет невидимого участка>, <цвет подписи> :. Автору статьи доводилось видеть (и активно создавать) классы, напрямую не связанные с рисованием, но содержащие десятки различных цветов. Причём все эти переменные инициализируются в конструкторе, обрабатываются в функциях чтения, записи и т.п. . Вместо этого можно сразу добавить в наш класс массив цветов, и использовать первый элемент этого массива для рисования звеньев ломаной, второй - вершин, третий - выделенных участков и т. д.. Теперь инициализацию, чтение и запись можно написать один раз, и в дальнейшем, для добавления нового цвета, достаточно будет увеличить размер массива. Некоторые неудобства появятся, если данный класс одновременно модифицируют несколько программистов. Так, один из них может использовать пятый элемент массива как <цвет подписи>, а другой - как цвет <невидимого участка>. Обычно такие недоразумения быстро выясняются и их легко исправить, поменяв значение константы, но параллельная разработка проекта при этом осложняется. Практически избежать таких ошибок позволяет использование вместо простого массива цветов ассоциативного массива.
Ассоциативный массив1 (см. например [4]) - массив, содержащий пары ключ (key) - отображаемое значение (mapped value). Зная ключ, можно получить доступ к значению. Как первое, так и второе, может иметь произвольный тип. В нашем случае в качестве ключа можно использовать строки (имена переменных), а в качестве отображаемого значения - цвета. Так, для цвета выделенного участка будет использоваться ключевое слово <цвет_выделенного_участка>, цвета узла - <цвет_узла> и т. д. При этом вероятность неверной интерпретации переменной существенно уменьшается, для добавления нового цвета нет необходимости увеличивать размер массива в описании класса - он будет расширяться по мере необходимости. При сохранении объекта будет сохраняться и ассоциативный массив: количество записей в нём и сами пары ключевое слово - значение. Теперь даже не встаёт вопрос совместимости различных версий программы: объекты <читаются>, даже если в них меньшее или большее количество переменных, чем в текущей реализации. Итак, проблему с цветами мы решили. Если для каждого элемента линии потребуется задавать толщину - добавим ассоциативный массив толщин, стиль (строковая переменная) - стилей и т.д. К сожалению, каждый раз придётся переписывать чтение-запись объектов, заботиться о совместимости версий... В какой-то момент количество таких массивов тоже перейдёт все разумные пределы. Напрашивается добавить ассоциативный массив, значениями которого являются ассоциативные массивы, но это даже звучит тяжеловато. Нет, массив у нас будет один, а в качестве значения - структура, содержащая информацию о типе переменной и её текущем состоянии. Можно использовать структуру variantarg, но удобнее создать собственные аналоги.
/*
Пример структуры - упрощённого аналога variantarg
*/
class baseclass;
struct _variant
{
short type;
union
{
baseclass *baseclass_value;
char *string_value;
colorref color_value;
double double_value;
long long_value;
/*
Можно добавить date, __int64, bool и т.д.
...
*/
};
};
А если необходимо добавить новый метод? Допустим, мы хотим завести у класса line метод smooth, сглаживающий линию. Создадим новый класс smooth_line, содержащий метод smooth(line *), <динамически добавим> в класс line новую переменную - указатель на объект этого класса, и, при необходимости сгладить линию, будем вызывать эту функцию. При этом мы не только получили возможность добавлять и перекрыть метод, не создавая новых подклассов модифицируемого класса (для этого достаточно заменить выполняющий данный метод объект), но и делать это во время исполнения программы с уже созданными и функционирующими объектами (например, пользователь может выбрать метод сглаживания).
Динамически формируемые объекты
Итак, нам нужен класс, интерфейс которого можно модифицировать во время исполнения программы (например, в зависимости от того, какие загружены модули, выбора пользователя, выполненных с этим объектом операций). У него должны быть методы, позволяющие добавлять (и удалять) переменные, проверять наличие необходимой переменной, её тип, получать значение и присваивать новое. Оказывается, реализовать такой класс очень просто.
Сначала создадим специальный класс - registry (реестр - по аналогии с реестром windows). Данный класс будет содержать ассоциативный массив, в котором содержатся динамически добавленные переменные (пары ключевое слово - тип_значение), методы позволяющие сохранять и загружать этот массив, осуществлять доступ к его содержимому и освобождать всю используемую память при удалении объекта. Функции формальной проверки корректности естественно также возложить на объект реестр: он может выдавать предупреждения и сообщения об ошибках, можно даже завести warning level (уровень строгости ошибок, для которых выдаётся предупреждение) как в ms visual studio. Так, при добавлении переменной, если запись с таким ключевым словом уже есть и имеет другой тип - можно выдавать сообщение об ошибке, а можно просто менять её: просто <старая переменная> после этого будет не определена. Для базовых типов данных удобно создать отдельные методы, работающие только с переменными данного типа. Для указателей (на объекты) в любом случае придётся получать указатель на void или на некоторый базовый класс, а затем приводить его к нужному типу. Для корректности такого приведения необходимо располагать информацией о типе объекта на этапе выполнения программы (rtti - real-time type info). Здесь можно использовать конструкции, предоставляемые языком программирования, например dynamic_cast в c++ (см. [4]), или включать информацию о классе в сам объект (более подробно это разобрано в [1]).
Теперь, что бы сделать класс динамически формируемым, достаточно добавить в него реестр и методы работы с ним. Для каждого объекта такого класса будет создаваться (по мере необходимости) собственный реестр, сохраняться и загружаться вместе с объектом. Переменные и методы класса, которые добавляются с использованием реестра, будем называть реестровыми.
Теперь мы можем добавлять новые переменные различных типов (и удалять их) во время выполнения программы, причём не во все объекты класса, а только в те, которым это необходимо!
Что это даёт?
Перечислим основные преимущества реестровых переменных и дополнительные возможности, появляющиеся при их использовании.
Возможность модифицировать класс, когда его код недоступен.
При использовании коммерческих библиотек, поддержке разработанного другой фирмой продукта часто приходится работать с классами, код которых недоступен. Иногда код имеется, но менять там что-либо крайне нежелательно (так бывает с базовыми библиотеками, одновременно используемыми многими программистами).
Допустим, мы хотим добавить в один из <закрытый> класс line переменную color. В такой ситуации непосредственная модификация класса невозможна. Иногда можно создать новый класс, унаследованный от данного, и добавить необходимые переменные туда. Но это не решает проблемы, если где-то в закрытом коде <прописано> создание объектов класса line, и для этих объектов также требуется использовать новую переменную. Кроме того, если в системе есть классы, производные от line (например, rect, circle), придётся создавать новые расширения и для них. Часто в базовые классы вставляют void* указатель на пользовательские данные (user data), но использование реестра гораздо удобнее и безопаснее.
<Плачу только за то, что использую>.
Возможность по мере необходимости менять интерфейс отдельных объектов класса.
Часто переменные класса реально используются только некоторыми его объектами. Например, в проекте может быть сотни линий, рисуемых предложенным по умолчанию чёрным цветом, и только для одной-двух пользователь задаст индивидуальный. Если ему просто не нравится чёрный, можно выбрать другой цвет по умолчанию. Иногда переменная имеет смысл только для некоторых объектов данного класса. Можно создать для таких объектов специальный подкласс, но это только усложняет ситуацию, особенно если необходимость в переменной может возникать и отпадать в процессе работы с объектом. При использовании реестра новая переменная добавится только в те объекты, где она реально необходима. Выигрыш памяти может даже окупить затраты на хранение имён и информации о типе.
Возможность централизованной обработки реестровых переменных.
При добавлении переменной обычно приходится вставлять её обработку в некоторые стандартные методы класса: инициализацию в конструкторы, копирование при создании копии объекта, сохранение и чтение. При этом, новая версия программы должна читать старые документы, и желательно, чтобы старая - новые. Для реестровых переменных все эти операции (и ряд других) выполняются автоматически. Можно даже написать диалог редактирования всех реестровых переменных объекта и добавления новых. Простейший вариант - лист свойств (propertysheet), в котором каждому типу данных (строка, число, указатель на объект, дата:) соответствует страница с таблицей <Ключевое слово> - <Значение>. А можно сгруппировать реестр в древовидную структуру и редактировать его в стиле известной утилиты regedit.exe (работа с реестром windows).
Возможность расширения нединамических классов.
Допустим, у нас есть <обычный> класс line, который мы решили не менять, и динамический line_drawer, объекты которого рисуют линии. В процессе эксплуатации у пользователя возникает пожелание задавать свой цвет для каждой линии. Естественным решением является добавить в line_drawer ассоциативный массив цветов, ключами которого будут некоторые идентификаторы линий, а значениями - их цвета. Но у этого класса уже есть ассоциативный массив, который пишется, читается и копируется вместе с объектом! Составим ключевое слово из имени новой переменной и идентификатора линии, и новый атрибут класса line добавлен. Конечно, такое решение не самое эффективное, но если линий не может быть слишком много: (по этому поводу см. ниже <Когда переменную не стоит делать реестровой> п. 3).
Предотвращение <засорения> интерфейсов базовых классов.
При развитии программы часто возникает необходимость добавлять новые переменные и методы в базовые классы, хотя они могут и не вписываться в уже существующий интерфейс. Как правило, это можно объяснить неправильным проектированием самих классов. Но неправильно оно с точки зрения возникшей в данный момент <сиюминутной> потребности! Мы же не можем заранее предвидеть все <капризы> заказчика (и он не может!), или перепроектировать всю систему по несколько раз в день. При бесконтрольном расширении часто используемых базовых классов их интерфейс разрастается, засоряясь ненужными для работы самих объектов данными и методами. Если необходимость в такой переменной отпала, её просто так не выкинешь: может перестать собираться какой-нибудь другой модуль (конечно, можно выкинуть переменную color, оставив методы getcolor и setcolor, но тогда уж, пусть остаётся). Реестровая же переменная <отомрёт> сама собой: её просто перестанут добавлять.
Возможность хранить конфигурацию системы (настройки пользователя), не связываясь с реестром windows.
Если у вас есть собственный реестр (который сохраняется, загружается и редактируется в диалоге), вы без проблем можете завести настройки пользователя (options) для всей программы, каждого проекта, окна и т.д.
<Тут критик воскликнет...>
К сожалению, в жизни за всё приходится платить. За предоставляемую динамически формируемыми объектами гибкость - тоже. Можно выделить несколько основных возражений против их использования.
Снижается эффективность программы.
Использование реестровых переменных требует значительно большей памяти: кроме значения хранятся её имя (размер которого может превышать размер значения в десятки раз) и тип. Кроме того, поиск переменной в реестре едва ли повысит быстродействие.
Опасность возникновения ошибок.
При использовании реестровых переменных и методов могут возникать некоторые специфические ошибки.
Конечно, вряд ли стоит делать все объекты динамически формируемыми, а переменные и методы - реестровыми. Однако, как показывает опыт, при разумном использовании реестра, недостатки оказываются практически неощутимыми, а преимущества - впечатляющими.
Некоторые рекомендации по использованию реестровых переменных
<Как вы яхту назовёте, так она и поплывёт>
Выбор ключевого слова для реестровой переменной имеет гораздо большее значение, чем имени для обычной. Действительно, основной опасностью при работе с реестром является возможность использования одного и того же ключевого слова в разных целях.
Вероятность данной ситуации особенно велика при независимой разработке отдельных модулей. Иногда это даже удобно - независимые компоненты приложения могут таким образом обмениваться данными (например, переменная цвет, объявленная в одном модуле может использоваться в другом), но может и привести к ошибке. Собственно, могут возникнуть ошибки двух родов. Во-первых, неверная интерпретация типа переменной: тот же цвет может храниться как целое четырёхбайтовое, однобайтовый индекс в палитре, массив, содержащий значения интенсивности красного, зелёного и синего (rgb), и даже как указатель на объект некоторого класса. Во-вторых, неверная интерпретация содержания переменной: реестровый метод recalculate, добавленный в другом модуле может пересчитать не данную линию, а совсем другой объект, цвет относиться не к самой линии, а к выводящейся рядом подписи, дата - датой создания, последней модификации и даже удаления. Для исключения ошибок первого рода достаточно строго контролировать соответствия типов запрашиваемого и возвращаемого значений переменной. Что касается ошибок второго рода, то от них не застрахован никто. Правда, для обычной переменной класса можно написать комментарий, а при абсолютно независимой реализации модулей (каждый из которых добавляет в один и тот же объект свои реестровые переменные) комментарии просто не доступны разработчикам из других групп. Здесь можно предложить использовать более конкретные названия реестровых переменных и методов, например: цвет линии, цвет подписи, дата создания и т.д. Кроме того, можно включать в них имя модуля, тогда эти переменные будут <невидимы> в остальных.
Когда переменную не стоит делать реестровой
Добавить реестровую переменную значительно проще, чем обычную. Не надо переписывать чтение, запись и пр., или даже заводить новый класс. Иногда возникает соблазн <засунуть> в реестр переменную, которую правильнее вставить в описание класса или специально созданного потомка. Для того чтобы избежать многих ошибок и потери производительности программы не стоит делать переменные реестровыми (а если делать, то очень осторожно) в следующих случаях:
При наличии ограничений целостности, связывающих данную переменную класса с другими.
В приводившихся выше примерах в случае потери значения переменной можно было практически без ущерба использовать некоторое умолчательное значение (например, чёрный цвет). Если же в переменной хранится количество элементов в некотором массиве, её потеря (например, при совпадении ключевых слов, используемых разными программистами) может привести к сбою в работе всей системе, потере данных. Вообще, если новая переменная по смыслу вписывается в интерфейс класса, стоит её туда и вставить.
Значение переменной <часто> меняется, или обращение к ней не удаётся <вынести за цикл>.
Иногда бывает удобно добавить в класс счётчик в некотором цикле, причём хочется сделать это, не меняя описание класса (то есть использовать реестр). Тут надо смотреть насколько обращение к реестру замедлит работу программы в данном конкретном случае. Если это происходит при рисовке каждого пикселя экрана - лучше поискать другой вариант. А если в промежутке между обращениями к данной переменной осуществляется интерполяция поверхностей, обращение к жёсткому диску и т. п., то замедления <никто и не заметит>.
Атрибут нединамического класса, количество объектов которого может оказаться критически велико.
Выше отмечалась возможность расширять нединамический объект, составляя ключевое слово из имени переменной и его идентификатора. Иногда это бывает очень удобным, но если расширяемых таким образом объектов окажется слишком много, затраты памяти и замедление работы программы могут оказаться недопустимыми. К сожалению, количество объектов (и даже его порядок) не всегда известно заранее. Так, в программу, которая проектировалась для работы с десятком-сотней скважин, рано или поздно, может потребоваться загрузить семнадцать тысяч:.
Когда класс действительно стоит сделать динамически формируемым
В отличие от переменных, которые не всегда стоит делать реестровыми, <динамичность> для классов практически не имеет противопоказаний. Действительно, объект registry создаётся только по необходимости, указатель на него - занимает всего четыре байта (вы, надеюсь, не создаёте специальный объект для каждого пикселя экрана?). Перечислим ситуации, когда использование реестра наиболее эффективно.
Класс будет предоставляться без исходного кода. (Это иногда случается с классами из коммерческих библиотек.)
Необходима возможность оперативно вносить в данный класс незначительные изменения. (А когда она не нужна?)
Невозможно заранее определить все применения объектов класса.
Объекты класса содержат большое количество взаимно независимых настроек пользователя.
Сочетание с другими паттернами проектирования
В последнее время было предложено довольно много методов проектирования гибких, легко модифицируемых и повторно используемых систем (см. [1],[2],[3]). В основе большинства из них лежит сочетание использования двух приёмов расширения функциональности классов: наследования и композиции объектов. Наследование даёт возможность расширять функциональность уже существующих классов путём порождения подклассов, а композиция - с помощью объединения объектов. Недостатком наследования является его статичность: интерфейс и реализация класса должны быть полностью определёны на момент компиляции. При использовании композиции объект должен иметь указатели на другие объекты группы. Это заставляет жёстко фиксировать структуру группы, накладывает ограничение на интерфейсы входящих в неё объектов. Реестровые переменные позволяют динамически менять состав группы, добавлять указатели на объекты классов, неопределённых на момент компиляции. Ещё одним понятием, тесно связанным с композицией, является делегирование. При делегировании объект поручает выполнение операций другому объекту - уполномоченному. При использовании делегирования, вместо того, чтобы создавать подкласс и перекрывать метод, достаточно заменить уполномоченный объект. Преимущество такого подхода особенно хорошо видно на следующем примере. Пусть наш класс line имеет два независимых метода, скажем recalculate и draw, каждый из которых имеет по 10 модификаций. При использовании исключительно наследования, пришлось бы создавать 10 * 10 = 100 подклассов, а при композиции - 10 объектов, производящих recalculate + 10 , производящих draw, итого - 20! Причём, если появится новый способ отрисовки, в первом случае придётся создавать 10 новых классов (сочетание этого метода со всевозможными recalculate), а во втором - только один, реализующий данный новый метод. На этом принципе основан паттерн проектирования Стратегия (strategy или policy, см. [2]). В приведённом выше примере класс line содержит две стратегии, каждая из которых имеет 10 конкретных реализаций. Паттерн Стратегия позволяет динамически заменять методы объекта (стратегии), но не даёт возможность добавлять новые. Такую возможность даёт совместное использование данного паттерна с реестровыми переменными. Мы можем динамически добавить ссылку на объект-стратегию, использовать её для выполнения соответствующей операции, при необходимости заменять указываемый ею уполномоченный объект. Паттерн Шаблонный метод (template method) предлагает определять основу алгоритма в базовом классе и позволяет подклассам переопределять некоторые шаги, не меняя его структуру в целом. Например, метод отрисовки ломаной линии может состоять в последовательном применении к её звеньям метода рисования отрезка, а к вершинам - рисования точек, которые могут быть перекрыты у классов-потомков. При совместном использовании последних двух паттернов (конкретные реализации шагов алгоритма делегируются объекту-стратегии), мы получаем аналог Каркасного Метода Сборки, подробно рассмотренного в [3]. Использование реестровых переменных позволяет создавать шаблонные методы обработки объектов, независимо от самих объектов. Доступ к стратегиям таких алгоритмов может осуществляться через реестровые переменные объекта. Так, алгоритм рисования ломаной будет получать у объекта line его стратегии, осуществляющие отрисовку отрезков и точек, и применять их к звеньям и вершинам данной линии. В процессе работы пользователь может независимо менять стратегии для каждой линии.
При использовании многих структурных паттернов, вместо объекта используется некоторый другой, расширяющий его функциональность (паттерн Декоратор), или приводящий его интерфейс к требуемому виду (Адаптер). Допустим, указатель на уже существующий объект типа line необходимо вставить в массив указателей на drawing. Паттерн Адаптер предлагает создать новый подкласс, унаследованный от drawing, содержащий ссылку на линию и делегирующий ей выполнение операций. Теоретически, паттерн Декоратор позволяет динамически <возложить дополнительные обязанности на отдельный объект, а не на класс целиком>. Объект помещается в другой, называемый декоратором. Декоратор имеет тот же интерфейс, что и декорируемый объект, переадресует ему выполнение операций, но может выполнять и дополнительные действия до или после переадресации. Например, можно создать декоратор, который сначала вызывает отрисовку вложенного в него объекта, а затем рисует вокруг него рамку. К сожалению, сам объект ничего не знает о существовании декоратора, если пользователь захочет увидеть его в другом окне (или во время другого сеанса работы с программой), рамки уже не будет. Данная проблема решается, если поместить в исходный объект указатель на используемый декоратор. Аналогично, иногда удобно иметь возможность получить уже созданные адаптеры данного объекта (хотя бы, что бы не создавать лишних). Потребность в конкретных Адаптерах, Декораторах и Стратегиях невозможно полностью определить на этапе проектирования класса. Некоторые из них могут понадобиться при разработке дополнительных модулей, когда изменение класса нежелательно или даже невозможно. Кроме того, указатели на такие объекты <засоряют> интерфейс класса: он перегружается переменными и методами, необходимыми в каких-то конкретных применениях данного класса, но совершенно не нужных во всех остальных. Использование в качестве указателей реестровых переменных позволяет динамически добавлять, удалять и изменять их во время исполнения программы.
Реестровые переменные уже несколько лет с успехом применяется при разработке и расширении пакета dv-seisgeo [6].
