Dynamiczne Proxy - jak działa?

Cześć

Czy ktoś by mi mógł wyjaśnić po co się stosuje dynamiczne proxy, skąd płynie wygoda stosowania tego wzorca projektowania, w jakich zastosowaniach. I jak w poniższym kodzie wywołują się kolejne metody. Czytam dokumentację i artykuły ale nie mogę za diabła tego zrozumieć...

Czytam Thinkig in Java i autor podaje taki przykład:

//: typeinfo/SimpleDynamicProxy.java
import java.lang.reflect.*;

interface Interface {
  void doSomething();
  void somethingElse(String arg);
}

class RealObject implements Interface {
  public void doSomething() { print("doSomething"); }
  public void somethingElse(String arg) {
    print("somethingElse " + arg);
  }
}	

class DynamicProxyHandler implements InvocationHandler {
  private Object proxied;
  public DynamicProxyHandler(Object proxied) {
    this.proxied = proxied;
  }
  public Object
  invoke(Object proxy, Method method, Object[] args)
  throws Throwable {
    System.out.println("**** proxy: " + proxy.getClass() +
      ", metoda: " + method + ", argumenty: " + args);
    if(args != null)
      for(Object arg : args)
        System.out.println("  " + arg);
    return method.invoke(proxied, args);
  }
}	

class SimpleDynamicProxy {
  public static void consumer(Interface iface) {
    iface.doSomething();
    iface.somethingElse("bonobo");
  }
  public static void main(String[] args) {
    RealObject real = new RealObject();
    consumer(real);
    // Wstawienie proxy i ponowne wywołanie:
    Interface proxy = (Interface)Proxy.newProxyInstance(
      Interface.class.getClassLoader(),
      new Class[]{ Interface.class },
      new DynamicProxyHandler(real));
    consumer(proxy);
  }
}

oraz pisze:
"[...]. Dynamiczne proxy będzie przekierowywało wszystkie wywołania do tejże implementacji (chyba autor miał na myśli interfejs Interface odnośnie kodu powyżej), więc konstruktor obiektu obsługującego wywołania (****Jakiego obiektu?) zwykle otrzymuje w wywołaniu referencję obiektu docelowego (jakiego obiektu docelowego?), tak aby mógł delegować do niego wywołania po wykonaniu swoich zdań dodatkowych."

Kompletnie tego nie rozumiem.

1. Kiedy i gdzie wywoływana jest metoda invoke interfejsu InvocationHandler?
2. Czy mógłby mi ktoś rozpisać w punktach jak to kolejno przebiega, co się po kolei dzieje?

Co do zwykłego proxy to rozumiem, że jest sobie pewien interfejs Inter z metodą method(). Ten interfejs implementuje klasa X oraz klasa Proxy. Klasa Proxy w swoim konstruktorze przyjmuje jakiś obiekt impelemtujący interfejs Inter, powiedzmy że np. przekażemy obiekt X. Proxy w swojej implementacji method() interfejsu Inter oprócz jakiś swoich czynności wywołuje na rzecz obiektu przekazanego w konstruktorze dodatkowo jego wersje implementacji method interfejsu Inter. W ten sposób klasa Proxy dodała dodatkowe funkcjonalności do swojej implementacji metody method z implementacji method obiektu X, wywołując po prostu X.method().
Tak rozumiem zwykłe Proxy, czy to rozumowanie jest poprawne? Dynamicznego proxy w cale nie rozumiem :(

Dzięki za wszelką pomoc :)

@WojtekPoczatkujacy: no generalnie dynamic proxy jest odzwierciedleniem wzorca proxy.
Na przykładzie ktory ja wczesniej zaimplementowałem:

public final class InvocationCounter implements InvocationHandler {

  private int invocationCount;
  private final Map<?, ?> targetMap;

  public InvocationCounter(Map targetMap) {
    this.targetMap = targetMap;
    invocationCount = 0;
  }

  @Override
  public Object invoke(Object o, Method method, Object[] objects) throws Throwable {
    Object result = method.invoke(targetMap, objects);
    invocationCount++;
    return result;
  }

  public int getInvocationCount() {
    return invocationCount;
  }

}

oraz

@Test
  void testInvocationCounter() {
    //given
    final Map<String, Integer> map = new HashMap<>();
    final InvocationCounter invocationCounter = new InvocationCounter(map);
    final Map<String, Integer> proxyMap = (Map<String, Integer>) Proxy.newProxyInstance(
        Map.class.getClassLoader(),
        new Class[] {Map.class},
        invocationCounter
    );

    //when
    map.put( "", 3);
    proxyMap.put("Hello", 5);
    proxyMap.get("Hello");
    final int invocationCount = invocationCounter.getInvocationCount();

    //then
    Assertions.assertEquals(2, invocationCount);
  }

Wywołuje metody z interfejsu map, przechwytując wywołania za pomocą interfejsu. InvocationHandler w metodzie invoke ma argumenty:
Object o - jest to dynamic proxy które wywołuje ta metode
Method method - jest to wywoływana metoda z interfejsu który opakowujemy (czyli tutaj mam Mapę)
i Object[] objects - argumenty które potrzebuje ta metoda.
Teraz:

Object result = method.invoke(targetMap, objects)

wywołuje metodę na instancji HashMapy która przekazałem do Dynamic Proxy. Ale dzięki temu mogę dokonać dodatkową czynnośc jaką jest:

 invocationCount++;

Czyli zliczyć wywołanie metody. DynamicProxy służy głównie do różnych bajerów typu programowanie aspektowe

Okej, coś się zaczęło już rozjaśniać, dzięki ;) Ale mam jeszcze jedno pytanie:

public static Object newProxyInstance(ClassLoader loader,Class<?>[] interfaces, InvocationHandler h) throws IllegalArgumentException

Co powoduje loader? Jest to loader obiektu, którego metody będą wywoływane?
Tablica interfejsów jest po to, aby jeden obiekt proxy mógł obsługiwać kilka obiektów implementujących wymienione interfejsy? Tylko wtedy trzeba zmienić InovationHandler, tak?

Okej, coś się zaczęło już rozjaśniać, dzięki ;) Ale mam jeszcze jedno pytanie:

public static Object newProxyInstance(ClassLoader loader,Class<?>[] interfaces, InvocationHandler h) throws IllegalArgumentException

Co powoduje loader? Wiem, że ładuje klasy, ale po co się go przekazuje tutaj jako argument obiektu? Jest to loader obiektu, który ma być opakowany, którego metody będą wywoływane?

Tablica interfejsów jest po to, aby jeden obiekt proxy mógł obsługiwać kilka obiektów implementujących wymienione interfejsy? Tylko te interfejsy muszą dziedziczyć po sobie? No bo loader jest dla jednego interfejsu.

Za każdym razem gdy przekazuje się inny obiekt (impelementujący wybrane interfejsy wymienione w Class<?>[] interfaces) , do którego będzie delegowane wywołanie jakiejś metody, należy zmienić InovationHandler, tak?

Classloader jest potrzebny, ponieważ w ramach jednego procesu JVM możesz mieć wiele różnych wersji danego interfejsu załadowanych z różnych bibliotek, przez różne CL. Zatem należy wskazać, która konkretnie wersja jest używana.
Tablica interfejsów, bo w Javie możesz implementować wiele interfejsów. Proxy zachowuje się jak normalny obiekt i musi mieć wszystkie możliwości takiego obiektu. Oczywiście InvocationHandler musi obsługiwać wszystkie wywołania. Inaczej mówiąc mając klasę:

class MyClass implements Serializable, Iterable, MyInterface{}

musi być możliwość odwzorowania jej w ramach proxy.

Co do ostatniego pytania, to niekoniecznie. Po prostu musisz przekazać handler, a to czy on potrafi obsłużyć wywołanie czy nie nie jest istotne.

A rodzja interfejsu na jaki rzutujemy zależy od tego jakie metody ma wywoływać proxy? Odwołując się do powyższego przeykładu proxy może wywołać zaimplementowane metodu interfejsu Interface. Ale gdy zrzutujemy obiek proxy na Interface2, to proxy będzie mógł wywoływać metody tylko tej klasy. Taki jest cel tej tablicy interfejsów?
Z drugiej strony i tak trzeba utworzyć nowy obiekt proxy, aby użyć np. metod interfejsu Interface2, a nie Interface.

 
Interface proxy = (Interface)Proxy.newProxyInstance(
      Interface.class.getClassLoader(),
      new Class[]{ Interface.class, Interface2.class },
      new DynamicProxyHandler(real));

Z czego wynika dynamizm proxy wymieniony w nazwie?

Ale gdy zrzutujemy obiek proxy na Interface2, to proxy będzie mógł wywoływać metody tylko tej klasy. Taki jest cel tej tablicy interfejsów?

W sumie dobre pytanie

Z czego wynika dynamizm proxy wymieniony w nazwie?

Z tego że to się dzieje w runtime (nie na etapie kompilacji) i pozwala na różną magie taką na przykład jaką Spring odwala :)

No właśnie tej magii nie moge dostrzec, przykład który zamieściłem słabo to uwidacznia. Czy magia polega na tym, że program nie wie jakie obiekty przekażemy do utworzenia proxy? No bo w sumie DynamicProxyHandler przyjmie dowolny obiekt implementujący wskazane interfejsy.

Moje pytanie chyba sięga jeszcze głebiej: czym jest refleksja? Czy to tylko manipulowanie obiektami Class i ich metodami?

Reflection is a language's ability to inspect and dynamically call classes, methods, attributes, etc. at runtime.

Na przykład kontenery IoC takie jak Spring opierają się o refleksję do tworzenia grafu zależności. Dodatkowo, dynamic proxy albo CGLIB (to drugie to manipulacja bytecodem) pozwalają na stosowanie aspektów Poczytaj

Proxy jest uznawane za magiczne , bo może zrobić kuku (i robi).

import java.lang.reflect.Proxy;

public class DramatProxy {

    public static void main(String[] args) {
        Adder adder  = new VeriComplexAdder();
        Adder prxy = (Adder)Proxy.newProxyInstance(DramatProxy.class.getClassLoader(), new Class[]{Adder.class},
                (proxy, method, rgs) -> {
             return adder.add((Integer)rgs[0], (Integer)rgs[1])+1;
        });
        System.out.println( prxy.add(2,2));
    }
}

interface Adder {
    int add(int a, int b);
}

class VeriComplexAdder implements Adder{

    @Override
    public int add(int a, int b) {
        return a+b;
    }
}

W tym małym kodzie widać co się dzieje i nikogo nie zaskoczy, że 2+2 =5.
Ale w większym kodzie może być niezła jazda - szczególnie, że kod 2+2 jest wywoływany i na debugu (i testach!) i pozornie wszystko wygląda ok.

Niestety nie bardzo rozumiem, co powyższy kod miał przedstawiać. Nie widzę tu żadnego pierwiastka magiczności niestety :(

return adder.add((Integer)rgs[0], (Integer)rgs[1])+1;

+1 sprawia, że 2+2=5; Przypuszczam, że chciałeś zaprezentować, że łatwo o pomyłkę stosując Proxy.
@jarekr000000 możesz mi jeszcze wyjaśnić do czego służy ten class loader w dynamic proxy? I dlaczego użyłeś akurat loader dla klasy DramatProxy?
Kol. @Koziołek próbował mi to wyjaśnić, ale nie zbyt zrozumiałem... Interesuje mnie przykład, który uwidacznia różnice, jaka powstaje w działaniu kodu jeśli użyje się różnych class loader. Np. w przykładzie, który zamieściłem autor używa class loader interfejsu, który jest tablicy Object[]

  Interface proxy = (Interface)Proxy.newProxyInstance(
      Interface.class.getClassLoader(),
      new Class[]{ Interface.class },
      new DynamicProxyHandler(real));

A Ty użyłeś loader całej klasy.
Dzięki za odpowiedź:)

Chcesz prawdziwej magii to niestety musisz do Hogwartu.
W javie sa tylko proste iluzje.

Nazywamy to proxy magią (jedna z kilku), bo potrafi nieźle namotać w systemach. W takim Springu (po cichu używających proxy) twój kolega w zespole dodaje jedną adnotacje to swojej klasy, którą gdzieś upchnie w jakimś podłym jarzie... i już w całym systemie 2+2 = 5. Oczywiście zwyklenie jest to +1 tylko jakaś inna akcja, iu zwykle pisana w dobrym celu... ale potrafi namieszać, bo trudno taki kod znaleźć. W springu/java ee jest tyle tych proxy aktywnych, że prawie nie ma szans odnalezienia w debugu.

Classloaderem się nie przejmuj. To relikt starych czasów. Kiedyś odpalało się na jednej vm wiele aplikacji. Każda podaplikacja miała swój classloader, dzięki temu się nie kłóciły ze sobą (jedna klasa ze zmiennymi globalnymi mogła istnieć w kilku classloaderach i w każdym mieć inne pola statyczne). Zwykle był też parent classloader, ze wspólnymi klasami. Dodatkowo pewne classloadery miały np. ograniczenia w dostępie. Trochę jak procesy w linuxie.
Te hierarchia była czasem bardzo rozbudowana (servery java ee, osgi) - to powodowało trudne to ogarnięcnia błędy. W nowszych aplikacjach, gdzie nie używa się serwerów aplikacji (albo jesli juz to tzw. embedded) jest jeden classloader i cały problem znika.

Czyli rozumem, że można w miejsce classloadera w Proxy wpisać cokolwiek i aktualnie nie rzutuje to na działanie kodu, tak?

WojtekPoczatkujacy napisał(a):

Czyli rozumem, że można w miejsce classloadera w Proxy wpisać cokolwiek i aktualnie nie rzutuje to na działanie kodu, tak?

W normalniej aplikacji nie. Najlepiej podaj jakaś swoją klasę ( i jej classloader), dla zasady.

Jeśli trafisz na aplikacje z czasów kiedy ludzie rzucali kamieniami w dinozaury (Jboss, tomcat, wildfly) to wtedy się przejmuj, podanie swojej klasy (jak wyżej) będzie nadal zwykle dobrym rozwiązaniem, proxy będzie działać,.... tylko, że:

Uzywanie proxy w normalnym kodzie to (prawie) nigdy nie jest dobre rozwiązanie.
Tak jak: null, klasy Date, Calendar, java.io.File, Proxy należy do rzeczy, których nie powinieneś używać w aplikacjach.
To rak.

Proxy powstało na użytek frameworków, niskopoziomowych cudów. Ale frameworki oparte o proxy są własnie chore. Da się zrozumieć, że takiego użyjesz (Spring), bo wiele osób tak robi. Ale nie dorzucaj do tego dodatkowej własnej kupy. Ponad 95% procent tego co ludzie robią przez proxy da się zrobić normalnie.