Comments 10
несколько мыслей:
1. Использовать рефлекшн вбизнес коде — зло, но во вреймворке — нормально
2. Скорость рефлекшна сильно улучшилась в 1.5, 1.6
Кто будет писать и сопровождать код фреймворка?
Кто будет писать и сопровождать код аппликации?
Если фреймворк будет писаться одним сильным программистом и редко модифицироваться — ничего страшного, если код в нём будет сложным и с рефшекшном, главное облегчить жизнь программистам послабее, которые будут писать аппликацию.
1. Использовать рефлекшн вбизнес коде — зло, но во вреймворке — нормально
2. Скорость рефлекшна сильно улучшилась в 1.5, 1.6
Кто будет писать и сопровождать код фреймворка?
Кто будет писать и сопровождать код аппликации?
Если фреймворк будет писаться одним сильным программистом и редко модифицироваться — ничего страшного, если код в нём будет сложным и с рефшекшном, главное облегчить жизнь программистам послабее, которые будут писать аппликацию.
Вполне с тобой согласен. Но с моей точки зрения даже код фрейворка должен быть написан в таком стиле чтобы его потом могли мейнтейнить другие девелоперы (EJB контейнеры ведь не мейнтейнят только создатели, но в процесс разработки подключаются и другие, главное чтоб не ламеры чтобы не плодить макароны)
я тоже согласен!
Сейчас правлю большой проект (~ 10000 классов). и там рефлекшен. Отлаживать это — просто ад. Ходишь по коду при помощи полнотекстового поиска. и по другому никак.
добавлю свои мысли:
1. между интерфейсом и аннотациями должен быть баланс. Взаимодействие двух модулей — это обычно интерфейс. Реже аннотации в классе, чтобы не плодить не нужную иерархию интерфейсов
2. нельзя, понимаете, нельзя делать на аннотация что-то большое и сложное. Часто люди увлекаются и делают монстра с полу-динамическим кодом. Для больших проектов — это большое зло, там уследить за всем практически сложно, помогает статический анализ, а рефлекшен убивает статику.
Сейчас правлю большой проект (~ 10000 классов). и там рефлекшен. Отлаживать это — просто ад. Ходишь по коду при помощи полнотекстового поиска. и по другому никак.
добавлю свои мысли:
1. между интерфейсом и аннотациями должен быть баланс. Взаимодействие двух модулей — это обычно интерфейс. Реже аннотации в классе, чтобы не плодить не нужную иерархию интерфейсов
2. нельзя, понимаете, нельзя делать на аннотация что-то большое и сложное. Часто люди увлекаются и делают монстра с полу-динамическим кодом. Для больших проектов — это большое зло, там уследить за всем практически сложно, помогает статический анализ, а рефлекшен убивает статику.
Это правильно — интерфейс — это контракт. Аннотации — для метаинформации.
И вообще — чем меньше аннотаций и рефлекшна, тем больше проверок на этапе компиляции
И вообще — чем меньше аннотаций и рефлекшна, тем больше проверок на этапе компиляции
в добавление к первому пункту.
я часто использую аннотации в inner-классах. Тогда вся логика в одном месте и всё понятно.
Но это не бизнес логика, это вспомогательные фичи на отображение данных
я часто использую аннотации в inner-классах. Тогда вся логика в одном месте и всё понятно.
Но это не бизнес логика, это вспомогательные фичи на отображение данных
Хоть я и из мира .Net, влезу сюда :) В MS последнее время тоже любят второй подход, называют его Convention Over Configuration. Очень активно используется в Entity Framework Code-First. Что тут сказать: с одной стороны круто, не надо ничего конфигурировать, не нужно наследовать свои объекты от каких-то специальных типов.
Но, нужно помнить все конвенции наизусть и часто понять, почему что-то не работает становится довольно сложно. Правильно упомянули выше, что для более слабого программиста может быть совсем непонятно, что происходит. Магия — это круто, когда ты полностью понимаешь как она работает. А когда она реально выглядит как магия — ничего хорошего.
Так что мой вывод: стараться всегда прибегать к жесткой типизации, которая имеет очень много пользы. И идти по второму пути, только очень чётко взвесив плюсы и минусы. Дальше, если уж пошли, то не только реализовать фреймворк, но также подробно описать все конвенции, которые он создаёт, покрыть всё это понятными простым смертным тестами и назначить ответственного за поддержку.
Но, нужно помнить все конвенции наизусть и часто понять, почему что-то не работает становится довольно сложно. Правильно упомянули выше, что для более слабого программиста может быть совсем непонятно, что происходит. Магия — это круто, когда ты полностью понимаешь как она работает. А когда она реально выглядит как магия — ничего хорошего.
Так что мой вывод: стараться всегда прибегать к жесткой типизации, которая имеет очень много пользы. И идти по второму пути, только очень чётко взвесив плюсы и минусы. Дальше, если уж пошли, то не только реализовать фреймворк, но также подробно описать все конвенции, которые он создаёт, покрыть всё это понятными простым смертным тестами и назначить ответственного за поддержку.
Работать с классами определенными вторым способом можно не только через Reflection.
Можно генерировать реализацию соответствующего интерфейса в рантайме и разницы в скорости по сравнению с реализацией интерфейса руками вы практически не заметите.
Кроме того, в Java 7 появилась такая штука как MethodHandle, которая работает пошустрее.
Можно генерировать реализацию соответствующего интерфейса в рантайме и разницы в скорости по сравнению с реализацией интерфейса руками вы практически не заметите.
Кроме того, в Java 7 появилась такая штука как MethodHandle, которая работает пошустрее.
Ха! Из таких «авторитетных» статей и рождаются мифы о Java. Поменяем в тесте строчки usingReflection() и usingMethodHandles() местами и… о чудо! теперь Reflection работает гораздо быстрее MethodHandles :)
// Там в комментариях к статье автору указали на ошибку. А Reflection на деле все-таки быстрее.
// Там в комментариях к статье автору указали на ошибку. А Reflection на деле все-таки быстрее.
Sign up to leave a comment.
Ограничения через реализацию интерфейса против свободы через рефлекшн