KeyedCollection является типом словаря, который может быть непосредственно сериализирован к xml без любой ерунды. Единственная проблема - то, что необходимо получить доступ к значениям: колледж ["ключ"].Value;
Как насчет выполнения шагов с 1 по 3 сразу после создания объекта и сохранения набора аннотированных полей, которые вы получаете либо в самом объекте, либо путем сохранения отдельного map of class to set-of-annotated-fields?
Затем, когда вам нужно обновить введенные поля в объекте, извлеките набор либо из объекта, либо из отдельной карты и выполните шаг 4.
Другой вариант, как вы говорите, вы знаете несколько полей, о которых идет речь с самого начала, - это запросить только эти поля или методы.
Пример: см. getDeclaredMethod
или getDeclaredField
в java / lang / Class.html
Вы можете использовать существующие фреймворки, которые позволяют вводить зависимости при построении объекта. Например Spring позволяет делать то же самое с аспектным плетением. Общая идея состоит в том, что вы определяете зависимости bean-компонентов на уровне Spring и просто отмечаете целевые классы, чтобы посоветовать их создание объекта. Фактическая логика разрешения зависимостей вводится непосредственно в байт-код класса (можно использовать переплетение во время компиляции или загрузки).
Не знаю, хорош ли он, но этот проект выглядит так, как будто он сделает то, что вы хотите. Цитата:
Набор утилит отражения и разные утилиты, связанные с работа с классами и их полями без зависимостей, который совместим с java 1.5 и дженериками.
Утилиты кэшируют данные отражения для высокопроизводительной работы, но использует слабое / мягкое кеширование, чтобы избежать держать открытыми ClassLoaders и вызывать кеши существуют в памяти постоянно. Возможность отмены механизм кеширования с вашим собственным поддерживается.
Fastest way to do anything with reflection is to cache the actual Reflection API classes whenever possible. For example I very recently made a yet-another-dynamic-POJO-manipulator which I believe is one of those things everyone ends up doing at some point which enables me to do this:
Object o = ...
BeanPropertyController c = BeanPropertyController.of(o);
for (String propertyName : c.getPropertyNames()) {
if (c.access(propertyName) == null &&
c.typeOf(propertyName).equals(String.class)) {
c.mutate(propertyName, "");
}
}
The way it works is that it basically has that one controller object which lazyloads all the properties of the bean (note: some magic involved) and then reuses them as long as the actual controller object is alive. All I can say is that by just saving the Method objects themselves I managed to turn that thing into a damn fast thing and I'm quite proud of it and even considering releasing it assuming I can manage to sort out copyrights etc.