Мне нужен совет, какие сценарии динамический прокси оказался бы более полезным, чем обычный прокси.
Я приложил много усилий, чтобы научиться эффективно использовать динамические прокси. В этом вопросе следует отметить, что такие структуры, как AspectJ, могут выполнять в основном все, что мы пытаемся достичь с помощью динамических прокси, или, например, CGLIB можно использовать для устранения некоторых недостатков динамических прокси.
Использовать случаи
- Декораторы - например, выполнять ведение журнала при вызове метода или возвращаемые кешем значения сложных операций
- Подтверждение контракта. То есть, убедитесь, что параметры находятся в допустимом диапазоне, а типы возврата соответствуют принятым значениям.
- Адаптер - увидел какую-нибудь умную статью где-то, описывающую, как это полезно. Тем не менее, я редко встречаю этот шаблон дизайна.
Другие?
Преимущества динамического прокси-сервера
- Decorator: регистрировать все вызовы методов, например,
public Object invoke(Object target, Method method, Object[] arguments) {
System.out.println("before method " + method.getName());
return method.invoke(obj, args);
}
}
Шаблон декоратора определенно полезен, так как он позволяет использовать побочные эффекты для всех методов прокси (хотя это поведение является примером для использования аспектов...).
- Контракт: в отличие от обычного прокси, нам не нужно реализовывать полный интерфейс. Например.,
public Object invoke(Object target, Method method, Object[] arguments) {
if ("getValues".equals(method.getName()) {
// check or transform parameters and/or return types, e.g.,
return RangeUtils.validateResponse( method.invoke(obj, args) );
}
if ("getVersion".equals(method.getName()) {
// another example with no delegation
return 3;
}
}
Контракт, с другой стороны, дает только возможность избежать полного внедрения интерфейса. Опять же, рефакторинг прокси-методов будет бессильно отменять динамический прокси.
Заключение
Итак, я вижу здесь один реальный случай использования и один сомнительный прецедент. Что вы думаете?
