Комментарии 4
Когда узнаешь про рефлексию, пост процессоры и так далее — сразу возникает желание что-нибудь такое сделать в проде.
Но не надо!
Кастомный DSL уместен при разработке фреймворков (пусть и для внутренних нужд), но абсолютно вреден при повсеместной работе. В случае каких-либо багов приходится искать место где происходит магия, а это значительная потеря времени. Особенно для новичков.
Но не надо!
Кастомный DSL уместен при разработке фреймворков (пусть и для внутренних нужд), но абсолютно вреден при повсеместной работе. В случае каких-либо багов приходится искать место где происходит магия, а это значительная потеря времени. Особенно для новичков.
Что поделать, большинству действительно хватает Java 7, но определённому проценту разработчиков хочется вырасти за рамки «if not null». Несомненно, они и их код являются объектом ненависти со стороны первых, но их не остановить.
Речь же не про джаву, а про то, что код должен быть понятным и простым.
Пару лет назад я был таким же с шашкой наголо, но потом понял, что разработчикам не интересно учить DSL конкретного проекта, который больше нигде они не увидят.
Понятно что DSL Spring, Lombok, Hibernate и так далее учить нужно — они широко применяются.
Но широко применение собственных аннотаций в проектах — это зло
Пару лет назад я был таким же с шашкой наголо, но потом понял, что разработчикам не интересно учить DSL конкретного проекта, который больше нигде они не увидят.
Понятно что DSL Spring, Lombok, Hibernate и так далее учить нужно — они широко применяются.
Но широко применение собственных аннотаций в проектах — это зло
Спасибо за статью, довольно интересно. Тем не менее, мне кажется, что сам пример не слишком удачный.
Во-первых, вы заменили обычную инициализацию в конструкторе (заметьте, что у вас там был вызов super с константными аргументами) на сеттеры. Конструктор мне представляется предпочтительным, потому что в случае использования сеттеров можно получить не до конца инициализированный объект. Да и смысла в такой замене я не вижу: возможна ли ситуация, в которой PlanetMapper, унаследованный от AbstractMapper<Planet, PlanetDto>, будет использовать другие классы entity и dto?
Во-вторых, добавление новой сущности (аннотации) и замена простого вызова сеттера на магию BeanPostProcessor и reflection затрудняет отладку и поддержку кода, потому что в таком коде намного сложнее разобраться. Вероятно, «оценят Ваш скилл далеко не все» относится в первую очередь к этому аспекту. Кстати, имена полей в строковых константах, как в коде fieldName.equals(«entityClass»), обещают добавить веселья при рефакторинге: при переименовании компилятор не увидит проблемы, но в рантайме поле перестанет корректно инициализироваться.
Наконец, я так и не смог понять, какую проблему вы пытаетесь решить при помощи аннотации.
PS AOP в статье не увидел.
Во-первых, вы заменили обычную инициализацию в конструкторе (заметьте, что у вас там был вызов super с константными аргументами) на сеттеры. Конструктор мне представляется предпочтительным, потому что в случае использования сеттеров можно получить не до конца инициализированный объект. Да и смысла в такой замене я не вижу: возможна ли ситуация, в которой PlanetMapper, унаследованный от AbstractMapper<Planet, PlanetDto>, будет использовать другие классы entity и dto?
Во-вторых, добавление новой сущности (аннотации) и замена простого вызова сеттера на магию BeanPostProcessor и reflection затрудняет отладку и поддержку кода, потому что в таком коде намного сложнее разобраться. Вероятно, «оценят Ваш скилл далеко не все» относится в первую очередь к этому аспекту. Кстати, имена полей в строковых константах, как в коде fieldName.equals(«entityClass»), обещают добавить веселья при рефакторинге: при переименовании компилятор не увидит проблемы, но в рантайме поле перестанет корректно инициализироваться.
Наконец, я так и не смог понять, какую проблему вы пытаетесь решить при помощи аннотации.
PS AOP в статье не увидел.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Spring Annotations: магия AOP