Klassen Mehrere/Verschiedene Objekte umcasten

[robontop]

Hallo!

Ich habe folgendes nerviges Problem, aber es gibt hoffentlich eine ziemlich einfache Lösung die ich als Java Anfänger nicht kenne


Zum Problem:
Ich habe eine Liste aus ListItems

Jedes ListItem hat ein Attribut key in welchem sich ein Object des Typs GraphNode befindet

Jedes Objekt GraphNode hat verschiedene Attribute, oder z.B. wieder ein Attribut in welchem irgendein Objekt gespeichert ist.


So.. Wie kann ich jetzt direkt auf die Attribute in GraphNode zugreifen?
Ich habe es bisher so gelöst:

ListItem item1 = Liste1.head; //Das Element in der Liste welches ich betrachten möchte
GraphNode node = (GraphNode) item1.getKey(); //umcasten

node.attribut ..

Ich hohle mir also zuerst ein Element aus der Liste, speicher es zwischen, caste es um und kann dann darauf zugreifen.. Falls "node" jetzt allerdings wieder ein Attribut hat in welchem ein eigenes/anderes Object drin steht muss ich das ganze ja schon wieder machen!!!

Also ich weiß nicht genau ich da googeln muss. Aber das Problem muss man doch eleganter lösen können

Viele Dank im Voraus

Mit freundlichen Grüßen

 

[bone2]

Interfaces oder Vererbung

alle verschiedenen Implementierungen von Key implementieren ein GraphNodeInterface oder erben von z.B. GraphNode, wodurch alle benötigten Methoden und Attribute bekantn sind.

mit interface wäre es dann z.b:

GraphNodeInterface key = item1.getKey();
key.machGraphNodeAction();

 

[nillehammer]

Japp, etwas ausführlicher:
- Bündele die Methoden, die eine bestimmte Gruppe von Klassen haben soll, in einem Interface. Z.B. ein Interface GraphNode mit der methode getKey() z.B. ein Interface Key mit der Methode ???
- Verwende die Klassen des Collections API für Listen/Sets/Maps etc. diese sind generisch. D.h. Du kannst bei ihrer Deklaration den Typ der Elemente angeben. Damit kannst Du nur solche Elemente einfügen und bekommst auch nur solche Elemente heraus. Damit enfällt das händische Casten. Beispiel:

// alle modifikationsmethoden (bspw. add, delete, set) nehmen jetzt nur noch Instanzen von 
// GraphNode an. Alle Zugriffsmethoden (bspw get) liefern direkt einen GraphNode zurück
List<GraphNode> meineNodes= new ArrayList()<>;

-- Wenn Du lieber selbst Container-Klassen entwickelst, definiere die Returntypen der Methoden so, dass sie die von Dir definierten Interfaces zurück geben. Gggf. mache auch diese generisch, wenn Dir der Interfacetyp nicht reicht und Du die Implementierungsklassen brauchst (würde ich aber eher von abraten).

 

[Spacerat]

Ich nehme mal an, dass GraphNode bereits eine abstrakte Klasse bzw. Interface ist, sonst gäbe es dieses Problem nicht . Deswegen dachte ich grad' an Interfaces plus Generics... Dadurch wird's aber auch nicht eleganter. Selbst mit Reflection inkl. der Kenntnis des konkreten Typs, kommt man um verschiedene Casts nicht drum rum.
Wenn die Anzahl verschiedenen Attribute fest liegt, kann man höchstens noch mit Enums, Maps (statt Listen) und switch (statt instanceof) arbeiten.

 

[nillehammer]

Ich nehme mal an, dass GraphNode bereits eine abstrakte Klasse bzw. Interface ist, sonst gäbe es dieses Problem nicht

Gut, dann anders. Schreibe die Methoden so, dass sie den richtigen Typ zurück liefern. Also den Typ, der die Methoden bereit stellt, die man braucht. Von Containern mit gemischten Typen, würde ich abraten. Entweder diese gemischten Typen haben einen gemeinsamen Supertyp (Interface, Abstrakte Klasse, "normale" Klasse), der alles bereit stellt, was man braucht. Dann ist dieser Typ der zurück zu liefernde. Oder man teilt die Elemente auf verschiedene Container auf. Ich habe bei eigenimplementierten Sachen noch die die Notwendigkeit gehabt, gemischte Typen zu speichern und dann extern zu casten. Das ist mir nur bei komisch programmierten externen Libs (z.B. org.w3c.dom) so gegangen.

 

[bone2]

Ich nehme mal an, dass GraphNode bereits eine abstrakte Klasse bzw. Interface ist, sonst gäbe es dieses Problem nicht .

Eher anders herum oder?
Wenn es Abstract/Interface wäre, gäbe es das Problem nicht. Sehr wahrscheinlich sind es einfach nur ähnliche Klassen. Aber solange der TE nicht mehr postet als er will casten, können wir nicht mehr sagen, als das es wahrscheinlich Blödsinn ist und er doch Interfaces/Vererbung nutzen soll.

 

[Spacerat]

Eher anders herum oder?
Wenn es Abstract/Interface wäre, gäbe es das Problem nicht. Sehr wahrscheinlich sind es einfach nur ähnliche Klassen. Aber solange der TE nicht mehr postet als er will casten, können wir nicht mehr sagen, als das es wahrscheinlich Blödsinn ist und er doch Interfaces/Vererbung nutzen soll.

Tja... möglich. Liegt wohl an deinem Post, die mitunter sehr verwirrend ist, zumindest ist mir nicht klar geworden, warum du gerade ein GraphNodeInterface vorgeschlagen hast, wo es doch offensichtlich ist, dass "<ListItem>.getKey()" bereits etwas GraphNode ähnliches zurück gibt. Wenn also eine Klasse ein Interface benötigt, dann doch wohl ListItem.

interface ListItemInterface<T extends GraphNode> {
  T getKey();
}

So bräuchte man bei "getKey()" zumindest nicht mehr auf GraphNode casten.
Da mir aber der vorherige Rückgabetyp von "getKey()" völlig unbekannt ist (evtl. ein anderer Typ, der GrapNode zumindest implementieren sollte), ging ich davon aus, dass bereits vererbt wurde.

 

[bone2]

Weil, so wie ich das verstanden habe, er das casten will, was bei getKey() zurückgegeben wird. dementsprechend muss das nur die klasse, die sich hinter dem Attribut key verbirgt ein einheitliches graphnode interface implementtieren und nicht das item


[EDIT][STRIKE]ich bin gerade verwirrt, in welcher reinfolge wird gecastet?
ist[/STRIKE]
(b) a.getC()
logisch gleich [STRIKE]((b) a).getC()[/STRIKE]
[STRIKE]oder[/STRIKE] (b) (a.getC())[/EDIT]

 

[Spacerat]

Weil, so wie ich das verstanden habe, er das casten will, was bei getKey() zurückgegeben wird. dementsprechend muss das nur die klasse, die sich hinter dem Attribut key verbirgt ein einheitliches graphnode interface implementtieren und nicht das item.

Würde das Object welches "getKey()" zurückgibt nicht bereits eine GraphNode sein, würde der Cast erst gar nicht funktionieren (ClassCastException), aber anscheinend geht das ja. Das Problem des TO ist doch aber, dass er diesen cast vermeiden will. Daraus folgt, dass in ListItem der Rückgabetyp entsprechend angepasst werden muss. Also etwas in dieser Art vllt.:

interface GraphNode {
	
}

interface WasAuchImmer {
	
}

class ListItem<T extends GraphNode & WasAuchImmer> {
	@SuppressWarnings("unchecked")
	T getKey() {
		return (T) new Beides();
	}
}

class Beides implements GraphNode, WasAuchImmer {
	
}

...hier frag' ich mich nur, warum "Beides" nur ungechecked gecastet werden kann. Liegt evtl. am TypeErase.