Написание такого кода привело меня к выделению следующих особенностей:
- Самоанализ позволяет внедрить множественное конфигурирование на уровне самого кода, что делает систему гибкой и модульной.
- Определившись с интерфесом (я не имею ввиду java интерфесы) анализируемых классов не нужно делать никаких(!) измений в коде. Возможно только вы захотите использовать аннотации, что все равно остается весьма гибким решением. ;)
- Мы получаем независимость кода от существования и правильности CDI. Конечно, если вы правильно написали анализирующий код...
- Из логики кода уходит огромное количество лишнего кода, проверяющего возможность использования зависимостей.
- И самое привлекательное, что становиться возможным создать общий интерфейс обмена параметрами! Вам больше не нужно думать и беспокоиться о количестве параметров в вызываемом методе, вы просто создаете специальный объект, по свойствам которого и будет выбираться метод.
Достоинства весьма привлекательные для меня, но возможно они незначительны для других разработчиков из-за очевидных проблем:
- Очень непросто определить правила анализа кода в конкретном проекте.
- Сложно унифицировать данные правила для выделения универсального функционала.
- Интерфейс обмена параметрами далеко не всегда можно унифицировать даже в каком-то одном модуле в проекте без излишнего усложнения архитектуры.
Решение этих проблем может привести к созданию весьма удобного фреймворка, но пока достойного решения лично мне в голову не приходит... Хотя отдельные задатки такого функционала уже существуют в узкоспециализированных библиотеках (Spring Forms, Hibernate).
При всех прелестях, которые я для себя нашел в таком подходе нужно быть предельно осторожным с производительностью... Самоанализ сильно тормозит систему, поэтому использовать рефлексию необходимо только тогда, когда выигрыш от такого анализа (например, отсечение лишних вычислений), будет значительно больше чем потери от самоанализа.
Комментариев нет:
Отправить комментарий