Annotation oder Markerinterface?

[Tobias]

Hi,

einige meiner Klassen sollen signalisieren, dass man mit Ihnen etwas bestimmtes anstellen kann. Für diese Funktionalität sind keine weiteren Methoden von Nöten. Würdet ihr dafür ein Markerinterface oder eine Annotation benutzen? Und warum?

mpG
Tobias

 

[tfa]

Eher eine Annotation (wenn du dir Java >=5 erlauben kannst). Markerinterfaces sind unschön, da hier ja keine Schnittstelle definiert wird - was eigentlich Aufgabe eines Interfaces ist. Praktisch ein Missbrauch eines OO-Konzepts.
Interfaces hätten bloß den Vorteil, dass man Generics verwenden kann.

 

[Tobias]

Java 5 ist schon drin, sonst bräuchte ich nicht fragen ...

Aber was ist mit den praktischen Vorteilen eines Markerinterfaces, wie

- Unterstützung des instanceof-Operators,
- Typsicherheit bei der Übergabe an Methoden?

mpG
Tobias

 

[ms]

Was genau willst du denn mit dem Interface/der Annotation bezwecken?

ms

 

[Wildcard]

Das Problem an Marker Interfaces ist, das du sie nicht mehr los wirst.
Was ist, wenn du später eine Unterklasse brauchst, die die markierte Fähigkeit nicht mehr hat?

 

[SlaterB]

jede Unterklasse hat alle Eigenschaften der Oberklasse,
warum sollte hier der Standard der Vererbung nicht mehr gelten?

das hat natürlich zur Folge, dass man eher vorsichtig mit der Vergabe der Eigenschaft sein muss,
ich wundere mich immer wieder, warum all meine JFrames Serializable sein sollen

 

[Tobias]

Mh, der Punkt mit den Unterklassen, die die Eigenschaft nicht mehr haben, ist ein interessanter Ansatz. Es stimmt zwar, dass den Grundregeln der Vererbung folgend jede Unterklasse alle Eigenschaften der Oberklasse hat, aber in diesem speziellen Fall könnte ich mir durchaus Unterklassen vorstellen, die gerade die markierte Fähigkeit nicht mehr haben sollen (Auch wenn mir noch kein entsprechendes Beispiel eingefallen ist).
Dazu kommt eben die Tatsache, dass ich Markerinterfaces als "unschön" empfinde. Aber der Punkt "Typsicherheit" hat eben doch was für sich ...

Worum es geht: Ich habe (in meiner GUI-Bibliothek) einen Objektbaum, von dem einige Objekte als "assistenzbedürftig" markiert werden müssen. Diese Klassen werden dann besonders verarbeitet, wobei unter anderem Utility-Klassen zum Einsatz kommen, die nur mit assistenzbedürftigen Objekten arbeiten können. Hier würde ich das Prüfen der Eigenschaft "assistenzbedürftig" gerne dem Compiler zuschieben, statt mich da selbst drum kümmern zu müssen.

mpG
Tobias

 

[Wildcard]

Ich würde die das Erweiterungsobjekt Pattern empfehlen. Besonders gerne wird das zB in Eclipse benutzt.
Du erweiterst bestimmte Objekte um Fähigkeiten, ohne das sie explizit davon wissen müssen.
Angenommen du wilst prüfen ob ein Objekt 'Hilfsbedürftig' ist.
Mit Marker Interfaces:

if(object instanceof Hilfsbedürftig)
{
    Hilfsbedürftig o = (Hilfsbedürftig)object;
}

Mit Erweiterungsobjekt (alle Objekte die beliebig erweitert werden wollen implementieren IAdaptable):

IAdaptable adaptable = (IAdaptable)object;
Hilfsbedürftig o = adaptable.getAdapter(Hilfsbedürftig.class);
if(o!=null)
....

Im Adaptable Objekt selbst kannst du nun entweder selbst ein passendes Objekt zurückliefern, oder an einen Globalen Adapter-Manager weiterleiten (oder eine Kombination aus beidem).
Dadurch kannst du einer Klasse neue Fähigkeiten verpassen, ohne deren Code zu ändern.
Du erschlägst nicht nur deinen aktuellen Anwendungsfall, sondern noch unzählige andere.
Einfach alle erweiterbaren Klassen die Mini-Schnittstelle IAdaptable mit einer einzigen Methode getAdapter implementieren lassen.

 

[byte]

Wenn dann in o aber nichts drin steht, finde ich das auch nicht wirklich schön. Dann doch lieber einfach eine Annotation definieren. Eine Util-Klasse kann dann prüfen, ob eine Instanz die Hilfsbedürftig-Annotation trägt.

 

[Tobias]

Danke für eure Antworten. Das Erweiterungsobjekt-Pattern erscheint mir tatsächlich als Overkill, besonders, da in dem zurückgelieferten Erweiterungsobjekt nichts drin steht. Ich denke, ich werde es mit einer Annotation machen.

mpG
Tobias

 

[SlaterB]

> besonders

nun, das ist ja auch wieder zu unterkillen,
eine Map<Enum,Boolean> tuts ja auch, in der Enum stehen dann alle möglichen Eigenschaften zur Auswahl,
die kann man pro Objekt setzen und wieder auslesen

aber die Definition der Map ist auch so ganz schön aufwendig
(edit: ein Set reicht auch)