Каковы риски использования рефлексии? Все ли идет против ООП?Использует ли отражение отражение unOOPish?
Я начал использовать его легко в проекте C#, и теперь я нахожу его практичным во многих сценариях.
Спасибо.
Чтобы ответить на вопрос в заголовке: нет, не априори. Например, отражение может быть чрезвычайно удобным при внедрении заводов для создания объектов разных (но связанных) типов.
Тем не менее, это все детали реализации, и они обычно должны быть скрыты за общим интерфейсом. Отражение также имеет тенденцию быть довольно медленным, поэтому чрезмерное использование не рекомендуется. В основном, используйте его, когда нет другого (хорошего) решения, и нигде больше.
ООП на самом деле не оспаривает отражение в целом. Но не пытайтесь реализовать динамическую диспетчеризацию или прослушиватели/обратные вызовы, используя отражение, когда ООП будет адекватным.
ООП - это техника и структура, а не религия.
Вы не собираетесь грешить, если не используете его в своем проекте. Если вы знаете лучший способ, пойдите для этого. Разумное использование рефлексии может сэкономить вам много сложности.
Просто убедитесь, что он чист и читабель, поэтому ваши товарищи по команде не распинают вас. Отражение мощное, но с большой силой приходит большая ответственность и т. Д.
Нормальные языки OO, такие как Smalltalk, имеют отражение. Люди, использующие его, рассматривают языки без его практически непригодного использования. Возможность разума во время выполнения программы необходима для более крупных систем.
Отражение может разрушить инкапсуляцию и создать связь между классом и внутренней реализацией другого класса. Используется неправильно, это может привести к плохой разработке OO, но это не то же самое, что не объектно-ориентированное. В некоторых отношениях он также может использоваться для реализации того, с чем сталкивается традиционный код OO, например AOP (аспектно-ориентированное программирование). Пурист может видеть это как не-ООП, хотя я бы счел его отношением к суперсету.
Некоторые места, которые я нахожу отражение быть под рукой:
За исключением модульных испытаний, как правило, я размышляю только об общедоступных свойствах/методах, чтобы не нарушать инкапсуляцию и не создавать связь с внутренней реализацией.
Это зависит от того, что вы делаете с отражением ... Я использовал его для перечисления публичных API-интерфейсов, а также в Java (через библиотеки самоанализа), чтобы делать полезные вещи с помощью JavaBeans. Используется вдумчиво, это очень полезно.
Я думаю, что проблемы возникают не обязательно, когда вы начинаете использовать отражение, но когда вы используете его, чтобы разбить инкапсуляцию - заглянуть внутрь объектов, чтобы наблюдать и изменять иначе скрытое внутреннее состояние. Если вы не будете осторожны, жесткая связь и хрупкость могут быстро распространиться по вашим классам, как только инкапсуляция будет нарушена.
Все языки программирования OO поддерживают отражение в меньшей или большей степени. Некоторые поощряют его использование (например, Smalltalk, на одном конце спектра), а некоторые препятствуют его (например, C++, с другой). Относительная частота использования этих двух языков для реализации программного обеспечения, которое вы используете каждый день, может рассказать вам о желательности интенсивного использования рефлексии.
Обратите внимание, что это не попытка начать войну на языке - я на самом деле являюсь чем-то вроде вентилятора Smalltalk &, который собирается сегодня вечером сделать Squeaking.
Я прорефлексирую любое время, когда интерфейсы просто не режут его для вас, может быть, из-за непредвиденных изменений или потому, что вещи слишком сложны, чтобы четко определить это. Имейте в виду, что утка, набирая языки, такие как Python, реализована тем, что составляет отражение. Вы можете использовать метод только по имени, и он либо работает, либо бросает. Я рассматриваю отражение как бэкдор для утки, печатающей на статически типизированном языке. ИМХО, если вы не верите, что утиная печать в корне неверна и никогда не будет ее использовать, нет ничего плохого в размышлении, если этот код не критичен по производительности.
Большие системы, такие как, скажем, ядро Linux? Написан на C и определенно не поддерживает рефлексию. – 2009-02-10 19:55:22
Да. Усилия по разработке, поставленные в ядро Linux, невероятны. Его неэффективность с точки зрения затраченных усилий/принятой строки кода или сюжетной точки также. Подход монгольских ордов работает для ядра Linux, но нецелесообразен для почти каждого программного проекта –