Decorator Pattern in der Java API

[Ulfmann]

Guten Abend allerseits,

ich sitze grade an einer Dokumentation für ein AS-Projekt, in dem es um die Umsetzung eines Entwurfsmusters (GoF) geht. Unsere Wahl fiel auf den Decorator und um dem Ganzen einen angemessenen, theoretischen Nährboden zu geben, möchte ich demonstrieren, wo und wie das Pattern in der Java API verwendet wird.

Könnte mich jemand in Richtung einer Stelle stubsen außer zu den Streams (bzw. Reader und Writer)? Ich hätte gern ein Beispiel, was von mir aus auch weniger offensichtlich ist.

Jemand eine Idee?

Danke schonmal.

[perdian]

Ich hätte gern ein Beispiel, was von mir aus auch weniger offensichtlich ist.

Das widerspricht sich dann ein wenig. Ein Pattern soll ja gerade offensichtlich sein, um die Wiedererkennung zu fördern.

Nichtsdestotrotz - ein klassisches Beispiel wäre noch

java.lang.ClassLoader

(bzw. seine Implementierungen)

[Ulfmann]

Ein sehr interessantes Beispiel, danke.

Dennoch ein sehr Abstraktes und ich hab da einige Probleme im Verständnis der Systematik von ClassLoadern. Ich wäre hier um etwas Erklärung dankbar.

Was hier funktional mit der ClassLoader Klasse einher geht, ist die Klasse Class, mit der ich mich auch noch nie tiefer beschäftigt habe. Insofern bin ich noch regelrecht von dieser ungreifbaren Abstraktion irritiert. So, wie ich den kurzen Beschreibungstext der API verstehe, symbolisiert eine Instanz der Klasse Class etwas, was eigentlich zu keiner Klasse gehört?! Und jedes Objekt der Klasse Class () referenziert eine ClassLoader-Instanz, richtig?

Ich bin für meine Zwecke nicht wirklich auf dieses Beispiel angewiesen, aber einerseits sehe ich hier eine qualitative Aufwertung meiner Arbeit und andererseits möchte ich mein Wissen vertiefen. Es wäre super, wenn ich hierzu noch weitere erklärende Informationen bekommen könnte.

[perdian]

So, wie ich den kurzen Beschreibungstext der API verstehe, symbolisiert eine Instanz der Klasse Class etwas, was eigentlich zu keiner Klasse gehört?!

Nein, ganz im Gegenteil. In Java gehört (vom primitiven Typen abgesehen) alles zu einer Klasse bzw. alles ist Instanz einer Klasse.

java.lang.Class definiert dir Metainformationen zu einem bestimmten Objekt bzw. der Klasse dieses Objektes. Wichtig hier ist es sich den Unterschied zwischen Objekt und Klasse nochmal deutlich zu machen. Eine Klasse ist der Bauplan, nach dem ein Objekt erzeugt wird. java.lang.Class ist damit die programmtisch fassbare Variante dieses Bauplanes und stellt mir programmatisch Informationen über eine Klasse und die daraus erstellten Objekte zur Verfügung.

Und jedes Objekt der Klasse Class referenziert eine ClassLoader-Instanz, richtig?

Richtig. Eine Klasse wird immer von einem ClassLoader geladen und hat damit implizit eine Referenz auf denjenigen, der sie "in die Welt gebracht" hat.

[Ulfmann]

Eine Klasse wird immer von einem ClassLoader geladen und hat damit implizit eine Referenz auf denjenigen, der sie "in die Welt gebracht" hat.

Ok und jeder ClassLoader delegiert seine Such- und Ladeabsicht zunächst an seinen Parent. Das heißt, will ich eine Klasse von einer externen Quelle laden (die die Standard-Loader gewiss nicht finden werden), bau ich mir selbst einen und sag diesem, wo die Quelle liegt?

Beispielsweise so?

URL [] someURLs = {new URL("anyURL"), new URL("anotherURL")};

URLClassLoader myLoader = new ClassLoader (someURLs, new ClassLoader());

Habe ich damit schon meinen Standard-Loader um Funktionalität erweitert?

Die Sache mit java.lang.Class leuchtet ein, danke sehr.

[perdian]

Das heißt, will ich eine Klasse von einer externen Quelle laden (die die Standard-Loader gewiss nicht finden werden), bau ich mir selbst einen und sag diesem, wo die Quelle liegt?

Exakt!

Habe ich damit schon meinen Standard-Loader um Funktionalität erweitert?

Nein. Du kannst die Funktionalität des Standard ClassLoader nicht erweitern sondern nur einen neuen ClassLoader (den du dann mit den neuen Logiken angepasst hast) erstellen - der Standard Loader (oder wie er korrekt heisst: System ClassLoader) lässt sich nach dem Start der Anwendung nicht mehr verändern.

Das ganze ist ein wenig umfangreicher und lässt sich nicht eben in fünf Minuten erklären, am besten suchst du dir hierzu ein paar gute Tutorials und Beschreibungen im Netz.

[Ulfmann]

Das ganze ist ein wenig umfangreicher und lässt sich nicht eben in fünf Minuten erklären, am besten suchst du dir hierzu ein paar gute Tutorials und Beschreibungen im Netz.

Ich merk schon, sehr tief und technisch anspruchsvoll dieses Thema, dennoch (oder grad deshalb) interessant.

Was ich aber nicht vorhatte, war mir selbst einen eigenen ClassLoader zu bauen. Mir gehts ja immernoch um das Decorator Pattern in der API und wenn ich anfange, selbst Klassen zu schreiben, entferne ich mich zu sehr davon. Eine eigene Implementation wird in einem anderen Kapitel beschrieben - hier würde ich gern bei den existierenden Klassen bleiben und hatte gehofft, dass es (wenn man mal das ganze Drumherum ausblendet) ähnlich funktioniert wie bei den Streams - eine Ineinanderschachtelung von mehreren Objekten, die letztlich alle den gleichen Basistyp haben und - plump ausgedrückt - einer mehr kann, als der "Vorgänger".

Dann werd ich das Beispiel doch rauslassen - durch Halbwissen glänzen ist immer so 'ne Sache.