Если класс прокси уже существует до работы программы, то этот метод прокси называется статическим прокси. В этом случае класс прокси обычно определяется в коде Java. Обычно класс прокси и класс делегатов в статическом прокси -прокси -контакте реализуют один и тот же интерфейс или получены из одного и того же родительского класса.
1. Обзор
1. Что такое агент
Мы все знаем, что агенты WeChat просто продают товары от имени производителей, и производитель «поручил» агентам продавать товары для них. Что касается бизнес -агентов WeChat, прежде всего, когда мы покупаем у них вещи, мы обычно не знаем, кто является производителем, то есть «комиссар» для нас невидим; Во -вторых, деловые агенты WeChat в основном нацелены на людей в кругу друзей в качестве своих клиентов, что эквивалентно «фильтру» группы клиентов для производителя. Мы дополнительно абстрагируем микро-бизнес агента и производителя. Первый может быть абстрагирован как класс агента, а второй может быть абстрагирован как класс делегатов (класс агента). Используя прокси, обычно существует два преимущества и может соответствовать двум характеристикам микро-бизнес-агента, который мы упомянули:
Преимущество 1: он может скрыть реализацию класса делегатов;
Преимущество 2: Он может достичь развязки между клиентом и классом делегатов и может сделать некоторую дополнительную обработку без изменения кода класса делегата.
2. Статический прокси
Если класс прокси уже существует до работы программы, то этот метод прокси называется статическим прокси. В этом случае класс прокси обычно определяется в коде Java. Обычно класс прокси и класс делегатов в статическом прокси -прокси -контакте реализуют один и тот же интерфейс или получены из одного и того же родительского класса. Ниже мы используем класс поставщиков для представления производителя и класса BusinessAgent для представления агента микро-бизнеса для представления простой реализации статических агентов. И класс делегирования, и класс Proxy реализуют интерфейс продажи. Определение интерфейса продажи следующее:
общественный интерфейс продавать {void sell (); void ad (); } Определение класса поставщика выглядит следующим образом: Общедоступный поставщик класса реализует Sell {public void sell () {System.out.println ("In Sell Method"); } public void ad () {System, out.println ("ad method")}} Определение прокси -класса BusinessAgent заключается в следующем:
Общественный поставщик класса реализует Sell {public void sell () {System.out.println ("In Sell Method"); } public void ad () {System, out.println ("ad method")}} Из определения класса BusinessAgent мы можем понять, что статические агенты могут быть реализованы посредством агрегации, так что класс агента может иметь ссылку на класс делегатов.
Давайте рассмотрим это требование ниже: добавьте функцию фильтрации в класс поставщиков и продам товары только студентам колледжа. Через статический прокси мы можем достичь его без изменения кода класса поставщиков. Нам просто нужно добавить суждение в метод продажи в классе BusinessAgent, и это может быть следующим образом:
Общедоступный класс BusinessAgent Reflames Sell {... public void sell () {if (iscollegestudent ()) {vendor.sell (); }} ...} Это соответствует второму преимущество использования прокси, упомянутого выше: он может достичь развязки между клиентом и классом делегатов, и может выполнить некоторую дополнительную обработку без изменения кода класса делегата. Ограничение статического прокси состоит в том, что вы должны написать класс прокси перед запуском. Давайте сосредоточимся на представлении динамического прокси -метода создания классов прокси во время выполнения.
2. Динамический агент
1. Что такое динамический прокси
Метод прокси, созданный классом прокси при запуске, называется динамичным прокси. То есть в этом случае класс прокси не определен в коде Java, но динамически генерируется во время выполнения на основе наших «инструкций» в коде Java. По сравнению со статическим прокси -сервером преимущество динамического прокси заключается в том, что он может легко обрабатывать функции класса прокси равно равномерно без модификации функций каждого класса прокси. Это более абстрактно. Давайте объединим пример, чтобы представить, как отражаются преимущества динамического прокси.
Теперь предположим, что мы хотим реализовать требование: вывод «до» до выполнения метода в классе делегатов и вывода «после» после выполнения. Мы представим класс поставщиков в качестве класса делегатов в приведенном выше примере, а класс BusinessAgent в качестве класса прокси. Во -первых, давайте использовать статический прокси для достижения этого требования. Соответствующий код выглядит следующим образом:
Общедоступный класс BusinessAgent Refrents Sell {Private Proder Mvendor; public BusinessAgent (поставщик поставщика) {this.mvendor = vendor; } public void sell () {System.out.println ("до"); mvendor.sell (); System.out.println ("после"); } public void ad () {System.out.println ("до"); mvendor.ad (); System.out.println ("после"); }} Из приведенного выше кода мы можем понять, что реализация наших потребностей через статический прокси требует, чтобы мы добавили соответствующую логику в каждый метод. Здесь есть только два метода, поэтому рабочая нагрузка не большая. Что если интерфейс продажи содержит сотни методов? В настоящее время использование Static Proxy напишет много избыточного кода. Используя динамический прокси, мы можем сделать «равномерное указание» для равномерного обработки методов всех прокси -классов без изменения каждого метода один за другим. Давайте представим, как использовать динамический прокси для реализации наших потребностей.
2. Используйте динамический прокси
(1) При использовании динамического прокси в интерфейсе InvocationHandler нам необходимо определить посредник, расположенный между классом прокси и классом делегатов. Этот посредник необходим для реализации интерфейса InvocationHandler. Определение этого интерфейса заключается в следующем:
публичный интерфейс villhainhandler {Object invoke (объект прокси, метод метода, объект [] args); } Из названия vocationHandler мы можем знать, что класс посредничества, который реализует этот интерфейс, используется в качестве «процессора вызова». Когда мы называем метод объекта класса Proxy, этот «вызов» будет перенаправлен в метод Invoke. Объект класса Proxy передается в виде Proxy Parameter. Метод параметра идентифицирует, какой метод мы называем класс прокси. ARGS является параметром этого метода. Таким образом, наши призывы ко всем методам в классе прокси станут вызовы для вызовов, поэтому мы можем добавить единую логику обработки в метод Invoke (или различные методы класса прокси можно обрабатывать в соответствии с параметрами метода). Поэтому нам нужно только вывести «до» в реализации метода Invoke в классе Mediation, а затем вызовут метод Anloke класса делегата, а затем выводит «после». Давайте реализуем это шаг за шагом.
(2) В соответствии с динамическим прокси -методом класса делегата класс делегатов должен реализовать определенный интерфейс. Здесь мы реализуем интерфейс продажи. Определение класса поставщиков заключается в следующем:
Общественный поставщик класса реализует Sell {public void sell () {System.out.println ("In Sell Method"); } public void ad () {System, out.println ("ad method")}} (3) Класс посредничества, как упомянуто выше, класс посредничества должен реализовать интерфейс InvocationHandler, так как процессор вызовов «перехват» вызовы в методах класса прокси. Определение промежуточного класса заключается в следующем:
Общедоступный класс DynamicProxy реализует InvocationHandler {Private Object obj; // OBJ - это объект класса делегатов; public DynamicProxy (Object obj) {this.obj = obj; } @Override public Object invoke (Object Proxy, Method Method, Object [] args) бросает Throwable {System.out.println ("до"); Object result = method.invoke (obj, args); System.out.println ("после"); результат возврата; }} Из приведенного выше кода мы видим, что промежуточный класс содержит ссылку на объект делегата, а соответствующий метод объекта делегата вызывается в методе Invoke (строка 11). Как вы думаете, это кажется знакомым, когда видите это? Удерживая ссылку на объект делегата с помощью метода агрегации, в конечном итоге преобразует все внешние вызовы, чтобы вызвать вызовы в объект делегата. Разве это не метод реализации статического прокси, который мы представили выше? Фактически, посредник класс и класс делегатов формируют статические прокси -отношения. В этих отношениях промежуточный класс является прокси -классом, а класс делегатов - класс делегации; Класс прокси и посредник также составляют статические отношения прокси. В этих отношениях промежуточный класс - это класс делегирования, а класс прокси - это прокси -класс. Другими словами, динамические прокси -отношения состоит из двух наборов статических прокси -отношений, которые являются принципом динамического прокси. Давайте представим, как «инструктировать» динамически генерировать прокси -классы.
(4) Динамические прокси -прокси -прокси -прокси -прокси -коды. Соответствующие коды
открытый класс main {public static void main (string [] args) {// Создать экземпляр динамического класса Mediation Class Inter = new DynamicProxy (new Vendor ()); // Добавить это предложение будет генерировать файл $ proxy0.class, который является динамически сгенерированной файловой системой класса прокси. GetProperties (). Put ("sun.misc.proxygenerator.savegeneratedfiles", "true"); // Получить экземпляр класса Proxy Sell Sell Sell = (sell) (proxy.newproxyinstance (sell.class.getclassloader (), новый класс [] {sell.class}, inter)); // Вызов метода прокси -класса через объект класса Proxy фактически перейдет в метод Invoke, чтобы вызовать sell.sell (); sell.ad (); }} В приведенном выше коде мы называем метод NewProxyInstance класса прокси, чтобы получить экземпляр класса прокси. Этот класс прокси реализует интерфейс, который мы указали, и будет распространять вызовы методов в указанный вызов. Объявление этого метода следующим образом:
Скопируйте код следующим образом: Public Static Object NewProxyInstance (ClassLoader Loader, Class <?> [] Интерфейсы, volcocationHandler h) бросает allosalargumentException
Три параметра метода следующие:
Загрузчик: определяет класснор класса прокси;
Интерфейсы: Список интерфейсов, реализованный Proxy Class
H: Вызовите процессор, то есть экземпляр класса, который мы определили выше, который реализует интерфейс InvocationHandler, давайте запустим его, чтобы увидеть, может ли наш динамический прокси работать должным образом. Вывод, который я запускаю здесь, является:
Это показывает, что наш динамичный прокси действительно работает.
Мы кратко упомянули принцип динамического прокси выше. Здесь мы кратко изложм: во -первых, мы можем получить экземпляр класса прокси с помощью метода NewProxyInstance, а затем мы можем вызвать метод класса прокси через этот экземпляр класса прокси. В методе прокси -класса мы на самом деле вызовут метод Anloke of the Mediation Class (называемый процессором). В методе Invoke мы называем соответствующий метод класса делегатов и можем добавить нашу собственную логику обработки.
Вышеуказанное - все содержание этой статьи. Я надеюсь, что это будет полезно для каждого обучения, и я надеюсь, что все будут поддерживать Wulin.com больше.