Динамическое добавление свойств в языке 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.