При сборке любой сборки в .NET (ASP.NET, Windows Forms, Командная строка, библиотека классов и т. Д.) В хранилище сборок также создается ряд «таблиц определений» метаданных. информация о методах, полях и типах, соответствующих типам, полям и методам, которые вы написали в своем коде.
Классы в пространстве имен System.Reflection в .NET позволяют перечислять и взаимодействовать с этими таблицами, предоставляя «объектную модель» для запроса и доступа к элементам в этих таблицах.
Одним из распространенных применений Reflection является обеспечение расширяемости (плагинов) для вашего приложения. Например, Reflection позволяет динамически загружать сборку из пути к файлу, запрашивать ее типы для определенного полезного типа (например, интерфейса, который может вызывать ваше приложение), а затем фактически вызывать метод для этой внешней сборки.
Пользовательские атрибуты также идут рука об руку с отражением. Например, инфраструктура модульного тестирования NUnit позволяет указать класс тестирования и методы тестирования, добавив атрибуты [Test] {TestFixture] в свой собственный код.
Однако тогда исполнитель тестов NUnit должен использовать Reflection для загрузки вашей сборки, искать все вхождения методов, которые имеют атрибут test, а затем фактически вызывать ваш тест.
Это сильно упрощает, но дает хороший практический пример того, где Отражение необходимо.
Отражение, безусловно, является мощным, однако имейте в виду, что оно позволяет полностью игнорировать фундаментальную концепцию модификаторов доступа (инкапсуляция) в объектно-ориентированном программировании.
Например, вы можете легко использовать его для получения списка закрытых методов в классе и их фактического вызова. По этой причине вам необходимо тщательно продумать, как и где вы его используете, чтобы избежать обхода инкапсуляции и очень тесно связанного (плохого) кода.