Я вижу много вопросов С#,.net, решенных здесь, используя отражение. Для меня многие из них выглядят как сгибание правил за счет хорошего дизайна (ООП). Многие из решений выглядят немыслимыми и "scripty".
Является ли использование отражения хорошей практикой в целом? Есть ли вещи, которые могут быть решены только отражением?
изменить:
Просьба привести примеры, в которых отражение является единственным хорошим решением.
Примеры:
Отражение - это инструмент, например "бросок". следует ли использовать везде? Нет! Так это запах кода для использования броска?
Для меня многие из них похожи на изгиб правила за счет хорошего дизайна (ООП). Многие из решений выглядят немыслимым и "scripty".
Честно говоря, "хороший дизайн" имеет мало общего с ООП. Я бы сказал, что гораздо больший дизайнерский запах, который нужно учитывать, - это убеждение, что хороший дизайн точно равен ООП. То, что у нас не может быть хорошего дизайна без ООП, и что мы не можем следовать правилам ООП, не становясь хорошим дизайном. Это почти так же плохо, как люди, одержимые "запахами". Программисты должны использовать свои мозги, а не их носы.
Является ли использование отражения хорошей практикой в Генеральная? Есть ли вещи, которые могут разрешается только отражением?
То, как я это вижу, отражение в основном является симптомом языковых недостатков. В идеале, язык должен позволять вам делать то, что вы хотите, без "сгибания правил" через отражение. Но большинство нет, и С# определенно не делает, поэтому отражение иногда является вашим единственным разумным выбором.
Существует множество "правильных" применений отражения. Динамическая загрузка типов/библиотек была бы очевидной. Или проверка атрибутов. Большинство модульных модулей тестирования также зависят от отражения, что прекрасно, потому что они должны быть немного навязчивыми, чтобы быть просты в использовании и получить доступ к коду, который мы хотим проверить.
Но большинство пользовательских кодов, которые выполняют некоторую проверку типов, тестирование во время выполнения, реализует ли тип определенный интерфейс или имеет определенную функцию-член, является признаком того, что на идеальном языке не должно быть необходимым.
Если вы хотите считать его запахом, назовите его языковым запахом, а не дизайнерским. (Конечно, это может быть слишком использовано в дизайне, но где я чаще всего сталкиваюсь с этим, это необходимость из-за отсутствия выразительности языка)
Отражение иногда является единственным способом делать определенные вещи. Это очень мощный инструмент, который иногда может быть чрезмерным для кого-то, кто хорошо знает рефлексию, но, возможно, не что-то другое. Более чем использование рефлексии, когда что-то еще будет работать лучше, может быть дизайнерским запахом... но чаще всего это просто плохое кодирование.
Однажды была программа, в которой обрабатывались файлы (как это общее описание)
Используя рефлексию, все, что вам нужно было сделать, это забросить DLL в папку, приложение подберет это и использует отражение, чтобы искать классы, которые реализовали определенный интерфейс и проверить некоторые атрибуты. Не было необходимости в конфигурационных файлах. Просто бросьте и идите, что было удобно для производственной системы, поскольку мы не требовали простоя.
Как и в большинстве решений. существует ряд других способов достижения той же цели, но рефлексия сделала это довольно легко.
Я бы не сказал, что использование отражения - дизайнерский запах. Это полезная особенность структуры, которая делает статистические языки немного более динамичными. Теперь с практической точки зрения я стараюсь избегать отражения, если я могу решить свою проблему без него.
По моему скромному мнению, размышление должно быть последним средством. Отражение делает код очень трудным для понимания, просто глядя на него, поскольку семантика языка может быть изменена очень странно.
Я бы подумал об этом запах. Может быть, неплохая практика, но что-то, что поднимет бровь.
Концептуально отражение - это мощный инструмент для использования в качестве шлюза из некода в код, а также полиморфный инструмент.
Например...
Используется надлежащим образом это гениальный инструмент для перехода на следующий уровень повторного использования и гибкости. Ничего плохого в этом.
Единственный раз, когда это запах дизайна, когда он используется для выполнения каких-либо обычных функций. (т.е. вы не захотите использовать Reflection для получения значений DataRow или чего-то еще).
С большой силой приходят большая ответственность, отражение - очень мощный инструмент, а при правильном использовании - очень хороший, при неправильном использовании это очень плохо, трюк заключается в том, чтобы знать, когда вы его используете
Как и в любой другой технологии, если вы слишком много внимания уделяете этому, вы можете начать применять ее к неправильным проблемам.
Есть вещи, которые просто невозможны без размышлений; Примером может служить любая общая сериализация. Другим может быть любой вид плагинов, который не во время компиляции имеет доступ ко всем классам, которые могут потребоваться для работы во время выполнения.
Есть некоторые проблемы, которые можно решить только с отражением, но я думаю, что его можно и, возможно, следует избегать везде, где это возможно. С# - это статический и безопасный по типу язык, поэтому используйте эти преимущества. Думаю, что использование отражения часто довольно подвержено ошибкам.
как и все, ответ "зависит"
Действительное использование рефлексии находится в рамках, например, плагиновая структура может использовать атрибуты для объявления классов плагина, еще один пример. Тестирование и Mocking Frameworks.
Но я бы согласился с тем, что, вообще говоря, в бизнес-приложении, большую часть времени это был бы "запах кода" (не всегда, хотя....)
Отражение позволяет проверять во время выполнения ту же информацию, которая использовалась компилятором во время компиляции. Следовательно, все, что вы можете сделать с отражением, может быть сделано без отражения во время компиляции. Это не означает, что отражение не имеет смысла: вы можете не знать, какой именно вопрос вы хотите задать до выполнения.
Если вы знаете что-то во время компиляции, выражайте его в системе типов. Это позволит вам ловить ошибки во время компиляции. Например,
string propVal = myObj.SomeProperty;
Здесь мы говорим, что во время компиляции мы точно знаем, что myObj имеет свойство, называемое SomeProperty, которое имеет тип, который присваивается string - и на самом деле, хотя он не отображается здесь, мы должны также указать тип класса или интерфейса myObj.
string propVal = (string)myObj.GetType()
.GetProperty("SomeProperty")
.GetValue(myObj, null);
Здесь мы говорим, что myObj может иметь такое же свойство - или это может быть не так (в этом случае мы получим исключение во время выполнения).
Второй, используя отражение, выглядит прикладом-уродливым, но в С# 4.0 он будет выглядеть практически идентичным. Он часто считается слишком медленным, но это зависит от контекста и, вероятно, будет менее справедливым для динамических функций в С# 4.0.
Реальное различие остается, хотя: статически типизированная версия помогает нам находить ошибки во время компиляции, вместо того, чтобы откладывать это открытие до времени выполнения.
Итак, если вы хотите в полной мере использовать систему статического типа для обнаружения ошибок во время компиляции, попробуйте указать свои предположения с помощью системы типов, что эквивалентно высказыванию: избегайте отражения, если это действительно необходимо.
Программирование - это создание абстракций. Отражение - очень мощный инструмент для создания абстракций. Так что нет, если это приведет к меньшему количеству кода, который будет легче понять, я бы не сказал, что это дизайнерский запах.
Некоторые из вас указали, что отражение имеет место в рамках, тестировании, mocks и т.д. Как насчет в бизнес-приложениях?
По моему опыту, когда вы пишете приложение для бизнес-бизнеса определенного размера, вы неизбежно заканчиваете тем, что пишете свою собственную инфраструктуру и библиотеки. То, где отражение имеет место.
Нет, Отражение - это не запах дизайна. Его можно было бы назвать "запахом языка/платформы".
Отражение используется, поскольку метаданные кода и кода хранятся в сборке. Таким образом, они всегда обновляются и синхронизируются. Вы можете кодировать общие соглашения по метаданным, а не быть явным в общем случае.
Для модульности в .NET очень полезно, чтобы модули самоописывались.
Это может быть связано с моим личным развитием как программистом, но я считаю, что рефлексия обучения защищает крайне необходимое внимание к результатам (сборкам). Наряду с TDD, конечно.
Одно приятное использование рефлексии - это когда вы хотите внедрить надстройку. Вам нужно каким-то образом указать "здесь DLL, загрузите его и попробуйте создать экземпляр типа". Вы не знаете тип перед рукой; все, что вы знаете, это то, что там есть какой-то интерфейс, к которому вы можете получить доступ. Единственный способ сделать это - отразить.
В нашем приложении имеется большое количество модулей, которые вы можете запустить внутри него. Вместо того, чтобы жестко кодировать список классов, которые мы должны запускать при выборе модуля, у нас есть таблица данных, в которой указано имя модуля DLL и класс для запуска из него. Таким образом, когда нам нужно добавить новый модуль, нам просто нужна новая запись в таблице. Код, запускающий модули, не изменяется.
Я нахожусь в середине проекта, который использует (для моего первого раза, когда-либо) Reflection. Должен признаться, это выглядит не очень хорошо. Обычно я стараюсь очень минимально комментировать, полагая, что код должен быть максимально комментирующим, но с этим проектом я добавляю частые комментарии; это также объясняет, что происходит с следующим разработчиком, которому, возможно, придется поддерживать код, и как "думать вслух" для моей собственной пользы.
Нижняя строка: если она не выглядит очевидной, добавьте комментарии. Всегда думайте о человеке, который приходит после вас, который может иметь дело с вашим беспорядком. Отражение может выглядеть беспорядочно, поэтому комментарий соответственно.
Нет его тяжелого использования отражения самой сеткой точек, которая заслужила такую популярность
использование F # сильно использует отражение
Ну, очевидно, что API-интерфейсы отражения есть, потому что они заполняют потребность, и есть некоторые проблемы, которые могут быть решены только с использованием рефлексии. В принципе, необходимо учитывать необходимость принятия решений в вашем коде на основе информации о типе, которая доступна только во время выполнения, но не во время компиляции.
Иногда это фактически улучшает повторное использование кода. В качестве конкретного примера я однажды написал программу для импорта csv в базу данных. Используя ORM для создания классов для таблиц, затем, размышляя над ними, я смог создать импортера, где должны были быть отмечены только исключительные ситуации, а добавление столбца, возможно, не требовало ничего, кроме добавления его в таблицу db, и зная, что он существует в файле.
Но, как заявили другие, это в основном проблема правильного использования.
Все отражения позволяют вам наблюдать типы во время выполнения. Если вы взломаны, я полагаю, вы могли бы скомпоновать некоторые из них с Рубе Голдбергом, но то же самое можно сказать о многих других методах.
Многие основные функции структуры, такие как атрибуты, не будут работать вообще без отражения.
Это один из самых вонючих запахов. Язык, который "полностью закрыт", не нуждается в отражении.
Любой может увидеть преимущества использования рефлексии, и я думаю, что отражение может помочь вам достичь лучшего дизайна и особенно концепций дизайна ООП без написания гораздо большего кода.
Например, вы можете создавать слабо связанные слои, которые зависят от абстракции и использования отражения для управления поведением, характерным для экземпляров во время выполнения.
Наиболее очевидно: обобщенные слои/компоненты пользовательского интерфейса.
Гибкость и производительность ASP.Net MVC и динамических данных - просто пример, вы также можете видеть GridView.