План доработки Dudge

1 План доработки Dudge
В ходе поиска путей добавления в систему модуля генерации
отчётности, был выявлен ряд других недостатков, связанных с архитектурой
системы:

в коде JSP страниц, логика, связанная с предобработкой данных,
которая должна была быть реализована в UI, добавлена с использованием
скриплетов. Скриплеты позволяют добавить в JSP страницы логику,
написанную на языке Java. Данный код будет выполняться на стороне
сервера, он может быть использован, например, для подготовки данных,
выводимых на странице. Скриплеты затрудняют вёрстку, поскольку их
использование приводит к смешиванию конструкций, написанных на java, с
кодом JSP страницы. Кроме того, в процессе вёрстки, разработчик может
внести в программу ошибку, обнаружение которой в дальнейшем зачастую
является сложной задачей, поскольку нарушение структуры кода в скриплете
не всегда влечёт за собой ошибку компиляции. В этой связи возникла
необходимость отказаться от использования скриплетов;

в классах DudgeBean и PermissionCheckerBean сосредоточена
практически вся основная бизнес-логика системы, при этом количество строк
кода в каждом классе превышает 700. Данный случай подходит под описание
анти-паттерна программирования Blob (Божественный объект). Антипаттерну Blob соответствует ситуация, когда в одном классе реализован
большой объём функционала различной направленности. Как правило, в
таких случаях родственный функционал выносится в отдельные классы;

классы сущностей в Dudge не являются POJO (Plain-Old Java
Object), поскольку кроме методов для получения и установки значений полей
они реализуют дополнительную бизнес-логику.
Поскольку указанные недостатки могут в дальнейшем привести к
значительному усложнению поддержки кода, их устранение является
приоритетной задачей. С целью устранения данных недостатков должен быть
осуществлён рефакторинг исходного кода Dudge.
2 План рефакторинга Dudge
2.1 Рефакторинг кода UI
Проблема смешения кода, написанного на java, с кодом, написанным на
HTML, javascript и CSS в теле JSP страниц, вызванная использованием
скриплетов, имеет 2 решения:
1) Отказаться
от
логики
в
коде
страниц
и
проводить
соответствующую предобработку данных в java классах.
2) Использовать специальные библиотеки тегов, которые позволяют
добавлять логику в JSP страницу, не нарушая её структуру.
Первый вариант решения проблемы требует глубокой переработки
кода программы, что потребует большего количества времени, но оба
решения практически равноценны в плане результата. В связи с этим, был
выбран второй путь.
Существует две библиотеки тегов, позволяющих решить данную
задачу: Jakarta Taglibs и JSTL. Для работы Jakarta Taglibs требуется, чтобы
приложение было развёрнуто на сервере приложений Apache Tomcat, в то
время как JSTL является частью JAVA EE, начиная с 5 версии. Dudge
использует для работы сервер приложений Glassfish. Ввиду указанных выше
ограничений, была выбрана библиотека JSTL.
JSTL представляет собой совокупность нескольких библиотек, каждая
из которых нацелена на решение определённых задач. В частности, в составе
JSTL есть библиотеки для реализации мультиязычности в приложении,
парсинга XML, использования в коде страниц сложных функций, и даже для
работы с базой данных.
Каждая из библиотек позволяет использовать на странице набор тегов.
Так, например, JSTL-core содержит следующие теги: catch, choose, forEach,
forTokens, if, import, otherwise, out, param, redirect, remove, set, url, when.
Каждый из них, в свою очередь, имеет несколько обязательных и
необязательных атрибутов. Например, атрибуты тега forEach включают:
begin, end, items, step, var, varStatus.
Важными отличиями JSP страниц, в теле которых используются
скриплеты, от JSP страниц, реализованных с использованием тегов JSTL,
являются следующие их свойства:

самоописательность – названия JSTL тегов раскрывают суть
реализуемой ими логики;

Используемые в документе JSTL теги должны образовывать
иерархическую структуру. То есть все открытые теги должны быть явным
образом закрыты, причём, если один тег был открыт внутри другого тега, он
должен быть закрыт там же – теги должны быть строго вложенными друг в
друга.
Второе свойство позволяет уменьшить риск внесения случайных
ошибок при редактировании страницы, поскольку нарушение структуры
тегов будет классифицировано средой разработки как ошибка, в отличие от
нарушения структуры кода, реализованного внутри скриплета.
2.2 Рефакторинг классов DudgeBean и PermissionCheckerBean
В
рамках
проведения
PermissionCheckerBean,
должны
рефакторинга
быть
классов
DudgeBean
последовательно
и
выполнены
следующие шаги:
 анализ кода на наличие неиспользуемых переменных, методов. Их
последующее удаление;
 анализ кода на предмет избыточной логики, избавление от неё;
 поиск дублирующегося кода, вынесение такой логики в отдельные
методы;
 уменьшение числа параметров, передаваемых в методы, там, где это
возможно;
 группировка методов по роду выполняемой ими работы, вынесение
родственных методов в новые классы.
Значительная часть бизнес-логики, содержащейся в классе DudgeBean,
может быть вынесена в отдельные классы: ContestDAO (рисунок 1), TestDAO
(рисунок
2),
LanguageDAO
(рисунок
3),
ProblemDAO
рисунок
4),
SolutionDAO (рисунок 5), UserDAO (рисунок 6). Каждому из этих классов
соответствует одна из сущностей, использующихся в системе.
Так, классу ContestDAO соответствует сущность Contest, а классу
LanguageDAO – Language. Логика методов, вынесенных в каждый из этих
классов, преимущественно связана с сущностью, соответствующей данному
классу.
Рис. 1 – UML-диаграмма класса ContestDAO
Рис. 2 – UML-диаграмма класса TestDAO
Рис. 3 – UML-диаграмма класса LanguageDAO
Рис. 4 – UML-диаграмма класса ProblemDAO
Рис. 5 – UML-диаграмма класса SolutionDAO
Рис. 6 – UML-диаграмма класса UserDAO
2.3 Рефакторинг классов сущностей
Классы сущностей – это классы, для которых реализовано объектнореляционное отображение на базу данных. Примерами таких классов могут
послужить Contest, Language, Problem, Solution.
В рамках проведения рефакторинга классов сущностей, требуется:
 проанализировать бизнес логику, реализованную в них;
 удалить ту часть логики, что нигде не используется;
 выделить родственные группы методов;
 для каждой из таких групп создать отдельный класс. В том случае, если
методы данного класса во время работы программы довольно часто
используются, они могут быть сделаны статическими.
3 Выводы
Таким образом, в результате анализа архитектуры Dudge, был выявлен
ряд недостатков. Такие недостатки, как:
 концентрация всей бизнес логики системы в нескольких классах,
 несоответствие классов-сущностей концепции POJO,
 смешение HTML и java кода в теле JSP страниц,
незаметны для пользователя, но при этом затрудняют сопровождение и
дальнейшее развитие системы. В этой связи, их устранение является
первоочередной задачей.