Действительно ли использование является отражением запах дизайна? [закрытый]

Примеры:

• Динамическая загрузка типов через конфигурацию
• Использование регистрации стиля «соглашения» (регистрация компонентов в вашем контейнере, реализующих интерфейс или имеющих определенное соглашение об именах)
• Проверка / использование настраиваемых атрибутов / метаданных типа

Отражение - это такой инструмент, как «бросок». нужно ли везде использовать throw? Нет! Так это запах кода для использования throw?

Нет, это интенсивное использование отражения самим каркасом точечной сети, которое принесло ему такую ​​популярность

. F # активно использует отражение

как и все, ответ - «это зависит»

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

Но я согласен, что, вообще говоря, в бизнес-приложениях большую часть времени это будет «запах кода» (хотя не всегда ....)

Все, что делает отражение, позволяет вам наблюдать за типами во время выполнения. Если вы - хакер, я полагаю, вы потенциально могли бы закодировать с его помощью какое-нибудь хитрое изобретение Руба Голдберга, но то же самое можно сказать и о многих других методах.

Многие основные функции фреймворка, такие как атрибуты, не будут работать вообще без размышлений.

Иногда это на самом деле улучшает возможность повторного использования кода. В качестве конкретного примера я однажды написал программу для импорта CSV в базу данных. Используя ORM для создания классов для таблиц, а затем размышляя об этом, я смог создать импортер, в котором нужно было бы отмечать только исключительные ситуации, а добавление столбца, возможно, не потребовало ничего, кроме его добавления в таблицу db, и зная, что он существует в файле.

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

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

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

Отражение позволяет вам проверять во время выполнения ту же информацию, что и компилятор во время компиляции. Следовательно, все, что вы можете делать с отражением, можно делать без отражения во время компиляции. Это не значит, что отражение бесполезно: вы можете не знать, какой именно вопрос хотите задать, до времени выполнения.

Если вы знаете что-то во время компиляции, выразите это в системе типов. Это позволит вам обнаруживать ошибки во время компиляции. Например,

string propVal = myObj.SomeProperty;

Здесь мы говорим, что точно знаем во время компиляции, что myObj имеет свойство с именем SomeProperty , которое имеет тип, который можно присвоить string. - и фактически, хотя это здесь не видно, мы также должны указать класс или тип интерфейса myObj .

string propVal = (string)myObj.GetType()
                       .GetProperty("SomeProperty")
                       .GetValue(myObj, null);

Здесь мы говорим, что myObj может иметь то же свойство, а может и не иметь (в этом случае мы получим исключение во время выполнения).

Второй, использующий отражение, выглядит некрасиво, но в C # 4.0 будет выглядеть практически идентично. Часто считается, что он работает медленнее, но это зависит от контекста и, вероятно, будет менее актуальным для динамических функций в C # 4.0.

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

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

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

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

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

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

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

Некоторые из вас отметили, что отражение имеет место во фреймворках, тестировании, имитаторах и т. Д. Как насчет в бизнес-приложениях?

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

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

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

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

Что ж, очевидно, что API отражения существуют, потому что они удовлетворяют потребность, и есть некоторые проблемы, которые могут быть решены только с помощью отражения. По сути, отражение необходимо, когда в коде необходимо принять решение на основе информации о типе, которая доступна только во время выполнения, но не во время компиляции.

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

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

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

Например ...

• , принимая строковое представление типа и превращения его в объект.
• не фреймворки жесткого кодирования или плагины вместе.
• динамически с использованием объектов из разные сборки, не зная что они собой представляют.
• сериализация данных без записи специальный код для этого.

При правильном использовании это гениальный инструмент, выводящий код на новый уровень повторного использования и гибкости. Ничего плохого в этом нет.

Единственный раз, когда это запах дизайна, - это когда его используют для чего-то, что уже покрывается обычной функциональностью. (т.е. вы не захотите использовать Reflection для получения значений DataRow или чего-то еще).

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

Одно из хороших применений отражения - это когда вы хотите реализовать архитектуру надстройки. Вам нужно каким-то образом указать «вот DLL, загрузите ее и попробуйте создать экземпляр типа». Вы не знаете тип заранее; все, что вы знаете, это то, что там есть какой-то интерфейс, к которому вы можете получить доступ. Единственный способ сделать это - использовать отражение.

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

Для меня многие из них выглядят изогнутыми правила ценой хорошего дизайна (ООП). Многие решения выглядят неподдерживаемый и «скриптовый».

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

Использование рефлексии является хорошей практикой в Общее? Есть вещи, которые могут можно решить только с помощью рефлексии?

На мой взгляд, рефлексия - это в основном симптом языковых недостатков. В идеале язык должен позволять вам делать то, что вы хотите, не «нарушая правила» посредством рефлексии. Но большинство этого не делает, и C # определенно не делает этого, поэтому иногда отражение - единственный разумный выбор.

Существует множество «правильных» применений отражения. Очевидно, что динамическая загрузка типов / библиотек. Или проверка атрибутов. Большинство фреймворков модульного тестирования также зависят от отражения, что нормально, потому что они должны быть немного навязчивыми, чтобы их было легко использовать и получить доступ к коду, который мы хотим протестировать.

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

Если вы хотите считать это запахом, назовите это языковым запахом, а не дизайнерским. (Конечно, в дизайне им тоже можно злоупотреблять, но там, где я чаще всего с этим сталкиваюсь, это необходимость из-за недостаточной выразительности языка)

Нет, Reflection - это не запах дизайна. Возможно, это можно было бы назвать «запахом языка / платформы».

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

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

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

Когда-то была программа, обрабатывающая файлы (насколько универсально это описание)

Используя отражение, все, что вам нужно было do было перетащить DLL в папку, приложение выбрало бы это и использовало отражение для поиска классов, реализующих определенный интерфейс, и проверки некоторых атрибутов. В файлах конфигурации не было необходимости. Просто бросай и работай, что было удобно для производственной системы, так как нам не требовалось простоев.

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

Это один из самых вонючих запахов. «Полностью закрытый» язык не нуждается в рефлексии.

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

Например, вы можете построить свободно связанные слои, которые зависят от абстракции и использования отражения для контроля поведения, специфичном к экземплярам во время выполнения.

Наиболее очевидно: обобщенные слои / компоненты UI.

Гибкость и производительность ASP.NET MVC и динамические данные являются лишь примером, а также вы можете увидеть GridView как один.

Я работаю над проектом, который использует (впервые в жизни) Reflection. Должен признать, выглядит не очень хорошо. Обычно я стремлюсь к минимальному количеству комментариев, веря, что код должен быть самокомментирующим в максимально возможной степени, но в этом проекте я добавляю частые комментарии; это как объяснение происходящего следующему разработчику, которому, возможно, придется поддерживать код, так и как «размышления вслух» для моей собственной выгоды.

Итог: если это не выглядит очевидным, добавьте комментарии. Всегда думайте о человеке, который придет после вас, и которому, возможно, придется разобраться с вашим беспорядком. Отражение может выглядеть неаккуратно, поэтому комментируйте соответственно.