🚀 go-pugleaf

Użytkownik "A.L." <alewando@kapturek62.com> napisał w wiadomości
news:64d1o1piv0eqv05hnb0dkb58hcgui2qpuh@4ax.com...
> On Sun, 20 Nov 2005 14:24:21 +0100, "Filip Sielimowicz"
> <sielim@poczta.onet.pl> wrote:
> > W Javie interfejsami można się posługiwać
> >nie tworząc żadnych klas, które by je implementowały. Można dynamicznie
> >tworzyć obiekty rzutowalne na dowolne interfejsy bez jawnego deklarowania
> >i definiowania klas implementujacych te interfejsy...
>
>
> Mozna prosic przyklad. W Javie. Od A do Z. Bo ja tego nie rozumiem.
>
> Interfejs to pewnego rodzaju "zapowiedz" funkcjonalnosi. Ktos te
> funkcjonalnosc musi gdeis i jakos zaimplementwoac. Wiec co to
> znaczy, cytuje: "W Javie interfejsami można się posługiwać nie
> tworząc żadnych klas, które by je implementowały...", konec cytatu.
> To ci sie dzieje jak metode zdefiniowana w interfejcie chcemy
> wywolac a nikt jej nie implementuje? Odsylamy do Swietego
> Mikolaja?... A moze klucz lezy w slowie "poslugiwac sie"?...

No więc odesłanie do Świetego Mikołaja jest dość bliskie prawdy.
W praktyce wygląda to tak, że dostarczamy nie tyle implementację
samej metody co funkcję interpretującą (handler) same wywołania
i decydującą co z nimi zrobić.

Tworząc obiekt proxy dostarczamy więc dwie rzeczy:
1. Listę interfejsów (do każdego z nich będzie rzutowalny)
2. Handler (Swięty Mikołaj z dużym workiem) odbierający
wszelkie odwołania do metod interfejsów - instancja klasy
implementującej java.lang.reflect.InvocationHandler. Handler
ten implementuje metodę invoke(...) w parametrach której otrzymuje
dokładny identyfikator metody (w javie jest to po prostu obiekt
klasy Method) i parametry, z jakimi była wywołana, sam zaś powinien
zdefiniować parametry wyjściowe (jeśli metoda była funkcją).

Tak więc implementację wszystkich metod interfejsów zastępuje
implementacja jednego handlera.

W tym sensie, z projektowego punktu widzenia, nie ma żadnych
klas implementujących interfejsy - bo klasa handlera ich
de facto nie implementuje, a to, co sobie robi JVM wewnętrznie
to już nas nie interesuje. Jedna klasa handlera może
obsługiwać nieskończone wariacje różnych interface'ów.
Teoretycznie cały system można zbudować bez definiowania klas,
dając same interfejsy i klasę handlera, która będzie wiedziała,
co z nimi robić. Np. będzie rozpoznawała wszelkie metody
rozpoczynające się w nazwie od "set"/"get" do realizowania
zapisu/odczytu własności obiektów funkcjonujących zgodnie
ze wzorcem TransferObject.

W praktyce, od strony niskopoziomowej, oznacza to, że przy
tworzeniu obiektu proxy zamiast instancji konkretnej klasy
implementujacej podane interfejsy zazwyczaj powstaje instancja
handlera (utworzona przez użytkownika) odpowiednio obudowana
przez JVM.

To, co wyżej widać to jest pewien początek. Bo majac
taki mechanizm możemy łatwo dynamicznie uzupełniać
obiekty implementujące dowolne interfejsy o kolejne interfejsy.
Dopóki posługujemy się samymi interfejsami i nie używamy
pojęcia klasy przy zaglądaniu do obiektów, doputy taka operacja
jest względnie bezpieczna - z tym zastrzeżeniem, że po drodze
zmienia się nam referencja, a więc mogą być kłopoty z
tożsamością obiektów, jeśli sami tego nie zapewnimy
w inny sposób.

BTW. Przykład w Javie od A do Z jest w linku, który podałem.