Диссертация (1090660), страница 22
Текст из файла (страница 22)
Его разработкавелась параллельно с разработкой ядра, и за счет этого обеспечивалось эффективное тестирование последнего. Следовательно, был необходим механизм, при помощикоторого можно разрабатывать блоки постепенно, по мере возникновения потребности внедрения того или иного функционала при тестировании ядра интерпретатора.И наконец, требовалось найти оптимальное решение для простоты реализации, чтобы дать возможность разрабатывать различные типы блоков независимо от других,без необходимости вносить радикальные изменения, которые могут повлиять на ихработоспособность.Следующим шагом стало определение основных типов, которые должны поддерживать блоки.
Согласно разработанной спецификации на данный момент существуетдва десятка типов блоков. Они рассмотрены в разделе 2.5. В результате стало понятно, что функции блоков не ограничиваются хранением примитивных данных, а ихприрода весьма вариативна в зависимости от типа.В результате вышеизложенного мы пришли к выводу, что реализовывать все блоки в едином классе нецелесообразно. С другой стороны, некоторые блоки похожи идолжны быть если не объединены, то, по крайней мере, связаны друг с другом путемнаследования.
Так, например, очевидно, что блоки “media”, “image” и “archive” хранят файлы и должны наследоваться от блока “file”, а блоки “url”, “phone”, “email” –от блока “string”, так как хранят строковые данные. Это обстоятельство стало первой предпосылкой формирования единой архитектуры. Поскольку модуль для работыс блоками должен быть универсальным, возникла необходимость разработки единого способа обращения ко всем типам. Результатом работы стал абстрактный класс“Block”. В нем внедрен единый интерфейс вызова всех типов блоков, единообразнособраны методы, используемые каждым блоком. Для начала были созданы перегруженные методы SetValue() (листинг 4.1), принимающие на вход аргумент одного из131типов: “string”, “long”, “int”, “double”. Целью такой перегрузки стала унификациявходных данных. Также реализован обратный метод GetValue(), возвращающий преобразованное сохраненное значение в строковом виде.Листинг 4.1.
Пример реализации перегруженной функции в модуле блокаbool SetValue(std::string value);bool SetValue(long int value);bool SetValue(double value);std::string GetValue();Позже был реализован метод SetParams(), принимающий вектор параметров конкретного блока и применяющий эти параметры. Вектор хранит их в виде структуры_Params (листинг 4.2), строковые поля которой являются соответственно именем параметра и значением. Другой метод, GetParam(), возвращает значение параметра попереданному в метод ключу (названию параметра). А метод GetParams() возвращаетсписок параметров в виде вектора. Метод принимает на вход значение одного из флагов или их побитовую сумму, определяющую, какой именно тип параметров долженбыть возвращен.
Это предусмотрено для того, чтобы сохранить возможность получить все необходимые данные (параметры) для любого модуля, с которым осуществляется взаимодействие по средствам ядра интерпретатора. Следующие флаги определены в заголовочном файле модуля блоков (Block.hpp): MODEL_PARAM (параметры,необходимые для обработки модели), LOCATION_PARAM (параметры, необходимыедля обработки локации), TEMPLATE_PARAM (параметры, необходимые для правильного отображения в шаблоне, а также дополнительные данные для отображения),DB_PARAM (параметры, влияющие на получение данных из базы) и ALL_PARAM.Последний является значением по умолчанию в методе getParams и возвращает всевыставленные параметры.Листинг 4.2. Перегруженные функции работы с параметрами и структураstruct _Params{std::string paramName;std::string value;};bool SetParams(vector<_Params > Params);std::string GetParam(std::string ParaName);std::vector<_Params>GetParams(unsigned char FLAG);132И поскольку базовый класс «Block» является абстрактным, эти методы не имеютреализации в нем.
Таким образом, все конкретные блоки должны наследоваться отэтого интерфейса и создавать реализации, характерные для их типа.В конечном итоге получается, что мы создаем экземпляр класса “Block” и черезнего обращаемся к конкретной реализации. Но возникает проблема: какую конкретную реализацию использовать и каким образом ее отделить от прочих реализаций.Например, как понять, что нам необходим блок типа “number”, а не “string”. Для наиболее гибкой реализации полиморфизма было принято решение использовать паттерн«абстрактная фабрика».В рамках нашей задачи необходимо создать класс, который будет «знать» о существовании всех реализаций типов блоков и способен их различить (в нашем случае этоосуществляется через указание имени типа блока).
В результате работы был образован класс BlockFactory, имеющий метод GetBlock (std::string type). Метод возвращаетсозданный объект конкретного класса блока с реализацией для своего типа данных,который приводится к указателю на класс Block (наш абстрактный интерфейс) (листинг 4.3, рис. 4.6).Листинг 4.3. Пример реализации перегруженной функции в модуле блокаBlock * content;BlockFactory * factory = new BlockFactory (util::Logger *log);content = factory.GetBlock("string");content.SetValue("something information...");На этапе реализации обнаружена неопределенная ситуация при незаданном илинекорректном типе.
В первом случае согласно спецификации по умолчанию все блоки имеют тип «string». И это автоматически делает допустимым отсутствие типа. Вслучае же задания абстрактному блоку некорректного значения возникает два сценария дальнейшего поведения: либо, как в первом случае, установить тип по умолчанию, либо вернуть указатель на NULL. Был выбран второй вариант, при этом, помимовозвращения пустого указателя, классом отправляется соответствующее исключение.4.2.1Альтернативные решенияПри выборе реализации модуля валидации и преобразования данных был рассмотрен другой паттерн проектирования, “Строитель” (Builder). Он отделяет алгоритм поэтапного конструирования сложного продукта (объекта) от его внешнего представления так, что с помощью одного и того же алгоритма можно получать разные пред-133Класс BlockКласс BlockFactoryМетодыМетодыSetValue();GetValue();SetParams();SetParam();GetParams();GetParam();GetBlock(std::string);Создание блока конкретного типаОбъектBlockFactoryВызов GetBlock(std::string);Объект BlockКонкретные типы блоковНаследуется от класса BlockНаследуются от FileBlockКлассыNumberBlockFloatBlockStrinngBlockDatetimeBlockFileBlockImageBlockMediaBlockРисунок 4.6.
Архитектура модуля блоковставления этого продукта. Поэтапное создание продукта означает его построение почастям. После «построения» последней части продукт готов к работе. Для функционирования паттерна Builder определяется алгоритм поэтапного создания продуктав специальном классе “Директор” (Director), а ответственность за координацию процесса сборки отдельных частей продукта возлагается на иерархию классов строителей(Builder). В этой иерархии базовый класс-строитель (Builder) объявляет интерфейсыдля построения отдельных частей продукта, а соответствующие подклассы их реализуют подходящим образом, например создают или получают нужные ресурсы, сохраняют промежуточные результаты, контролируют результаты выполнения операций.Для получения разных представлений некоторых данных с помощью паттерна “Строитель” директор должен использовать соответствующие экземпляры “Строителей”.Данный паттерн предназначен для создания разных объектов с одинаковой реализацией, что не подходит для нашей задачи, так как каждый блок в зависимости оттипа имеет свои особенности реализации, и все объекты блоков должны быть доступны через единый интерфейс, чего невозможно добиться с использованием паттерна“Строитель”.1344.3Выбор шаблонизатораДля генерации конечного документа, следуя шаблону проектирования MVC, помимо контроллера и модели, чьи функции принял на себя интерпретатор, требуетсятретья компонента — представление.
Представление получает данные от модели, накладывая их на заранее подготовленный шаблон. Функцию представления в настоящей работе выполняет шаблонизатор.Все данные, сгенерированные на основе логики работы интерпретатора, передаются в шаблонизатор. Затем шаблонизатор «склеивает» данные с шаблоном и на выходеотправляет готовый документ, как правило, в формате HTML, хотя это не обязательное условие.Этап генерирования конечного документа также требует значительного количества системных ресурсов. Так, в статье [116] представлен детальный сравнительныйанализ шаблонизаторов, разработанных на основе парадигмы конвейерной обработки [76] и не использующих функции обратного вызова. Для тестирования каждогошаблонизатора применялся тест «Lebowski Bench», во время прохождения которого генерировался документ HTML, в котором присутствуют элементы «традиционной» Web-страницы: разделы сайта, лента новостей, навигационные теги и др.
Тестыиспользуют одинаковый набор данных. Для каждого шаблонизатора создавался собственный шаблон таким образом, чтобы конечный результат максимально совпадал сисходной Web-страницей. Результаты тестирования представлены на рис. 4.7.Производительность шаблонизаторовСкорость работы, запросы всекунду10000Template Toolkit90008000HTML::Template70006000HTML::Template::Pro5000HTML::Template::Compiled40003000HTML::Template::JIT200010000HTML::CTPP2ШаблонизаторыРисунок 4.7. Результаты тестирования шаблонизаторовКак видно из диаграммы, шаблонизатор CTPP2 с большим отрывом превосходитостальные по производительности. При этом он поддерживает основной функционал,используемый в шаблонах: вставку внешних шаблонов, циклы, ветвления, именованные блоки и др.
Исходный код программной платформы написан на C++ и распро-135страняется по лицензии BSD, что никак не ограничивает использование платформыв диссертационном проекте. Кроме того, шаблонизатор поддерживает компиляциюшаблонов в байт-код, что может служить подспорьем в обеспечении производительности у критических по скорости проектов.4.3.1Особенности программирования шаблонизатораСуществуют реализации CTPP2 на PHP, PERL и C++. Различия в них заключаются исключительно в требованиях используемого языка программирования. Самоезаметное различие заключается в представлении данных.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
