Отражение: только для рамок?

Question

Кто-то, с кем я работаю и уважаю, однажды заметил мне, что не должно быть никакой необходимости в использовании отражения в коде приложения и что его следует использовать только в рамках. Он говорил из J2EE, и мой профессиональный опыт работы с этой платформой, как правило, подтверждает это; хотя я написал рефлексивный код приложения, используя Java один или два раза.

Мой опыт работы с Ruby on Rails радикально отличается, потому что Ruby во многом побуждает вас писать динамический код. Многое из того, что дает вам Rails, было бы просто невозможно без рефлексии и метапрограммирования, и многие из тех же техник одинаково применимы и полезны для кода вашего приложения.

• Согласны ли вы с точкой зрения, что рефлексия предназначена только для фреймворков? Мне было бы интересно услышать ваше мнение и опыт.

Answer 1

Есть старая шутка о том, что любая достаточно сложная система, написанная на языке со статической типизацией, содержит неполную, низшую реализацию Lisp.

Поскольку ваши требования, как правило, усложняются по мере развития проекта, вы часто в конечном итоге обнаруживаете, что общие идиомы в объектных системах статического типа в конечном итоге попадают в стену. Иногда стремление к размышлению - лучшее решение.

Я доволен динамически типизированными языками, такими как Ruby, и статически типизированными языками, такими как C #, но неявное отражение в Ruby часто делает более простой и легкий для чтения код. (В зависимости от требуемой магии метапрограммирования, иногда сложнее написать).

В C # я обнаружил проблемы, которые не могли быть решены без размышления из-за информации, которой у меня не было до времени выполнения. Один пример: при попытке манипулировать каким-либо сторонним кодом, который генерировал прокси для объектов Silverlight, запущенных в другом процессе, мне пришлось использовать отражение, чтобы вызвать конкретную строго типизированную «универсальную» версию метода, потому что для маршаллинга требовался сделать предположение о типе объекта в другом процессе, чтобы извлечь из него нужные нам данные, и C # не позволяет указывать «тип» вызова универсального метода во время выполнения (кроме как с помощью отражения техники). Я думаю, вы могли бы утверждать, что наш инструмент был своего рода фреймворком, но я легко мог представить случай в обычном приложении, сталкивающемся с подобной проблемой.

Answer 2

Отражение в Java обычно не требуется. Это может быть самый быстрый способ решения определенной проблемы, но я бы лучше решил основную проблему, которая заставляет вас думать, что это необходимо в коде приложения. Я верю в это, потому что он часто выталкивает ошибки из времени компиляции во время выполнения, что всегда плохо для достаточно большого программного обеспечения, что тестирование нетривиально.

Answer 3

Отражение определенно интенсивно используется в каркасах, но при правильном использовании может помочь упростить код в приложениях.

Один пример, который я видел ранее, - это использование JDK Proxy с большим интерфейсом (более 20 методов) для переноса (то есть делегирования) конкретной реализации. Только несколько методов были переопределены с использованием InvocationHandler, остальные методы были вызваны с помощью отражения.

Отражение может быть полезным, но медленнее, чем обычный вызов метода. Посмотрите это Сравнение отражений .

Answer 4

Отражение делает DRY намного проще. Конечно, можно писать СУХОЙ код без размышлений, но часто он гораздо более многословен.

Если какая-то часть информации закодирована в моей программе одним способом, почему не будет Я использую отражение, чтобы добраться до нее, если это самый простой способ?

Похоже, он говорит именно о Java. И в этом случае он просто ссылается на особый случай: в Java рефлексия настолько шаткая, что почти никогда не бывает легким способом что-либо сделать. :-) В других языках, таких как Ruby, как вы видели, это часто бывает.

Answer 5

Я думаю, что замечание о том, что не должно быть никакой необходимости в использовании отражения в коде приложения и что его следует использовать только в рамках, более или менее верно.

По спектру того, как связаны некоторые фрагменты кода, код, объединенный отражением, так же слабо связан, как и появляется.

Таким образом, код, который выполняет свою работу с помощью рефлексии, вполне может успешно выполнять свою роль в жизни, не зная ничего о коде, который его использует.

Answer 6

Если ваша проблема лучше всего решается с помощью отражения, вы должны использовать ее.

(Обратите внимание, что определение «лучший» - это то, что усвоено опытом:)

Определение фреймворка и приложения не так уж и черно-белое. Иногда вашему приложению требуется немного фреймворка, чтобы хорошо выполнять свою работу.

Answer 7

Используйте отражение, когда нет другого пути! Это вопрос производительности!

Если вы уже рассматривали подводные камни производительности .NET, возможно, вас не удивит, насколько медленным является нормальное отражение: простой тест с повторным доступом к свойству int оказался в ~ 1000 раз медленнее при использовании отражения по сравнению с прямым доступом в собственность (сравнивая среднее значение медианы 80% от измеренного времени).

См. Это: .NET отражение - производительность

В MSDN есть очень хорошая статья о Когда следует использовать отражение?

Answer 8

Я не согласен, рефлексия очень полезна в коде приложения, и я часто использую ее. Совсем недавно мне пришлось использовать отражение, чтобы загрузить сборку (чтобы исследовать ее открытые типы) только с пути сборки.

Здесь высказано несколько мнений на эту тему ...

Что такое отражение и почему оно полезно?

Answer 9

Я не согласен, мое приложение использует отражение для динамического создания провайдеров. Я мог бы также использовать отражение для управления потоком логики, если логика проста и не требует более сложного паттерна.

В C # я использую отражение, чтобы получить атрибуты из Перечисления, которые помогают мне определить, как отобразить перечисление для конечного пользователя.