Помимо сериализации, что было бы законным использованием отражения для доступа к частным членам?

Question

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

Какие другие (законные) варианты использования рефлексии вы можете найти для доступа к другим недоступным членам?

РЕДАКТИРОВАТЬ Я имею в виду вещи, которые вы не можете сделать, если у вас нет отражения.

Answer 1

На ум приходит юнит-тестирование.Если вы хотите протестировать закрытый метод, но не выставлять его или использовать InternalsVisibleToAttribute.

Answer 2

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

Модификатор общего / частного доступа является проблемой на уровне разработки приложений , и поле не должно быть открыто для того, чтобы сделать фреймворк счастливым.Примеры включают в себя такую ​​инфраструктуру, как Hibernate, которая управляет постоянством объекта , внедрение зависимостей инфраструктура, которая может вводить данные в приватное поле, или, в более общем смысле, сервер приложений , который работает независимо отмодификатор доступа.

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

Answer 3

Один - это сохранение объектов в БД. Например. Hibernate использует отражение, а в некоторых случаях, например, Идентификатор объекта может быть закрытым членом с частным установщиком / получателем, потому что он бесполезен в домене Java. Однако он необходим в БД, поэтому Hibernate устанавливает / получает его в фоновом режиме и использует для определения идентичности объекта.

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

Answer 4

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

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

Answer 5

Вы также можете использовать отражение, чтобы вызывать методы, основанные на параметре типа ввода (например, enum), тем самым, по существу, заменяя оператор switch.

например:

enter code here

   public class Test
   {
    public enum Status
    {
      Add,
      Delete,
      Update
    }

    public void Save(Status status)
    {
          //use reflection to obtain corresponding method
           MethodInfo method = this.GetType().GetMethod(status.ToString(),BindingFlags.NonPublic | BindingFlags.Instance);
         //Invoke method here

    }
    //you don't want to expose these methods
    private void Add()
    {

    }
    private void Delete()
    {

    }
    private void Update()
    {

    }
}

Answer 6

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

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