Динамическое добавление свойств в языке Java
Disclaimer Инструмент родился как способ побороть недочеты проектирования малой кровью. Я с трудом могу представить ситуацию, где использование инструмента могло бы быть продиктовано иными причинами.Предыстория Случилось мне однажды подключиться к разработке немолодого web-приложения. Код был местами изрядно запутан, хранил следы деятельности нескольких разработчиков разной квалификации, актуальных работоспособных тестов не было. Одно слово — legacy.Приложение было реализовано по классической трехслойной схеме: Persistence: Hibernate. Services: Spring. Endpoints: Spring MVC: JSP, RESTful. И на всех уровнях использовались сущности уровня хранения (далее — сущности). Из-за этого изменение имен свойств сущностей влекло за собой необходимость править код на клиенте или в JSP, а добавление чего-нибудь в JSON который отдавали контроллеры или в JSP, если это что-то не лежало в сущности, было крайне неудобным и рискованным из за отсутствия тестов.Как же протащить на уровень представления значения, которых нет в сущностях? Я рассмотрел несколько способов.Listener’ы и Interceptor’ы Listener’ы и Interceptor’ы позволяют добавить в сущности дополнительные данные. В некоторых случаях их применение оправдано, но предпочитаю не засорять сущности уровня хранения структурами и данными, не имеющими к уровню хранения никакого отношения.Mapping Можно пронаследоваться от каждого класса, который требует расширения, и начинить его нужными данными уже на сервисном уровне. Это концептуально верный путь: слой хранения сохраняет чистоту, слой контроллеров не требует модификации. Однако, возникают проблемы с производительностью, ленивая загрузка перестает быть ленивой, т.к. маппер не знает, какие из полей нужны контроллеру, и вынужден перекладывать все. Управление маппером со стороны контроллера теоретически возможно, но это невозможно без модификации кода контроллера.Dynamic proxy Немножко магии: package ru.bdm.reflection;
//some imports omitted
import static junit.framework.Assert.assertEquals; import static org.apache.commons.beanutils.PropertyUtils.getProperty;
public class PropertyJoinerTest {
public static class AnyType { public Object getAnyProperty () { return «anyPropertyValue»; } }
@Test public void testWithPropertyExtractor () throws Exception { PropertyJoiner propertyJoiner = new PropertyJoiner (new PropertyExtractor () { @Override public Object get (Object o, String property) { return property + «Value»; } }, «first», «second»);
AnyType src = new AnyType ();
AnyType dst = propertyJoiner.joinProperties (src);
assertEquals («firstValue», getProperty (dst, «first»)); assertEquals («secondValue», getProperty (dst, «second»)); assertEquals («anyPropertyValue», getProperty (dst, «anyProperty»)); } } Что под капотом? Динамически создаются классы интерфейсов для добавочных свойств: public interface FirstHolder{ Object getFirst (); } public interface SecondHolder{ Object getSecond (); } Динамически создается класс proxy, который наследует AnyType и реализует FirstHolder и SecondHolder.Методы, определенные в AnyType, proxy перенаправляет к src, методы, определенные в FirstHolder и SecondHolder, перенаправляются в PropertyExtractor, который содержит логику вычисления добавочных свойств.Таким образом мы получили возможность расширения представления, не меняя при этом код контроллеров и не засоряя сущности уровня хранения посторонними структурами и данными, не получая падения производительности из-за проблем с ленивой загрузкой.
Плата за это оказалась не очень велика: доступ к свойствам через прокси примерно в 150 раз медленнее, чем непосредственный. Это стоит учитывать при использовании инструмента.Нагрузка нашего приложения была всего несколько запросов в секунду, за каждый запрос читалось максимум 50 сущностей (размер страницы), так что долей потерь в proxy можно было пренебречь.
Скачать код можно с Google Drive.
