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

Question

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

Несколько мнений по этому вопросу выражены здесь ...

What is reflection and why is it useful?

Answer 4

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

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

Смотреть это: .NET reflection - performance

MSDN имеет очень хорошую статью о When Should You Use Reflection?

Answer 5

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

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

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

Answer 6

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

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

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

Answer 7

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

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

Отражение может быть полезно, но оно медленнее, чем обычный вызов метода. См. Это reflection comparison.

Answer 8

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

Answer 9

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

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

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