Interface-Problem

[gee_20_4_7]

Hallo Java-Freunde,

ich habe gerade folgendes Problem:
-es gibt ein Interface I, welches für die Klassen A,B,C,D,E als Vertrag gilt
-es gibt in einer Klasse Z eine List<I>, welche Objekte der obigen Klassen speichert
-es gäbe die Möglichkeit ein Enum als Parameter zur Verfügung zu stellen, welches angibt welcher Art die Ergebnis - Liste sein soll

Nun soll ich in Klasse Z eine Möglichkeit zur Verfügung stellen getypte Listen abzufragen.
Dieser Form: List<A> oder List<B> und so weiter.

Die einfache Variante 5 Methoden mit annähernd gleichem Code zu schreiben ist mir klar. Gibt es vielleicht auch eine Möglichkeit das alles in einer Methode abzuhandeln? Mittels Polymorphie oder ähnlichem?
Habe jetzt schon einiges probiert - bin aber immer wieder gescheitert, weil sich der generische Typ der Liste erst zur Laufzeit ergibt...

Danke schon mal im Voraus.

 

[faetzminator]

Es gäbe da instanceof, aber das find ich nicht sehr hübsch:

if (someObj instanceof A) {
    // do something ...
} else if (someObj instanceof B) {
    // ...
} // ...

aber eine Methode im Interface wär natürlich schon schön, warum hast du sonst das Interface?

 

[gee_20_4_7]

Danke für die zügige Antwort,

Die herangehensweise mit dem InstanceOf-Operator habe ich tatsächlich noch nicht probiert, aber ich denke, da werde ich wieder das gleiche Problem bekommen, wie bei meinen Versuchen vorher, denn es entscheidet sich ja erst nach Auswertung der Bedingungen welche Art Liste zurückgegeben werden soll. Gibt es da irgendwas, oder muss ich den hässlichen Weg gehen?

Das Interface habe ich aus Gründen der Erweiterbarkeit. Dort hängen ähnliche Klassen dran, die aber trotzdem manchmal auch getrennt behandelt bzw. benutzt werden müssen.
Wie meinst du das mit der Methode im Interface?

Gruß

 

[Käptn Blaubär]

public <E extends I> List<E> getValues(Class<E> type)
{
  final List<E> result=new ArrayList<E>();
  for(I value : yourList)
  {
    //hier gibt es viele Möglichkeiten, hier eine wenn wirklich nur Instanzen von A, B usw im result sein sollen
    if(type.equals(value.type))
    {
       result.add((E)value);
    }
  }
  return result;
}

 

[faetzminator]

ja, ich wär zb für ein

public final int type;

im interface, dann könntest du in den Konstruktoren der Klassen z.B. folgendes machen

public A() {
    type = THIS_IS_SOME_CONSTANT;
}

und dann für die Typisierung:

switch (someObj.type) {
case THIS_IS_SOME_CONSTANT:
    // ...
    break;
case [...]
default:
    throw new IllegalArgumentException();
}

 

[gee_20_4_7]

Oh das sieht sehr interessant aus... Werde ich gleich mal probieren!
Das extends gilt wohl auch für Interfaces, nicht nur für Basisklassen?
thx

 

[Noctarius]

Genau auch Interfaces kannst du ableiten (sogar Annotation-Interfaces um es genau zu sagen *gg*).

<E extends I> sagt, dass der Rückgabetyp eine Ableitung vom Interface I sein muss.

 

[gee_20_4_7]

Also ich habe es jetzt folgendermaßen gemacht:

 @SuppressWarnings("unchecked")
    public <E> List<E> getGetypteListe(final Class<E> type) {
	List<E> result = new LinkedList<E>();
	for (I i : theList) {
	    if (type.equals(i.getClass())) {
		result.add((E) i);
	    }
	}
	return result;
    }

Muss ich mir wegen der SuppressWarning Gedanken machen?
Hab da schon einiges gelesen - oft hieß es "geht nicht anders". Ist das richtig?

Nochmal zu dem extends im Platzhalter der von Käptn Blaubär angebotenen Parametrisierten Methode:
Das extends habe ich rausgenommen, weil es um Objekte geht, die nur das Interface implementieren und nicht um Objekte vom Interface abgeleiteter Klassen. Aber trotzdem großen Dank für den Ansatz!!!

Getestet habe ich die Methode schon - und sie funzt. Gibt es da noch irgendwelche Einwände?

@faetzminator:
Auch großen Dank an dich!
Das mit dem typeAttribut habe ich auch probiert... Wusste gar nicht, dass man in einem Interface Attribute angeben kann. Dieses sollte nur immer initialisiert werden und darum habe ich das verworfen. Konnte ja, da es sich um ein finales Attribut handelte, diesem auch nichts mehr zuweisen. Oder, wie meintest du das?

@Noctarius

<E extends I> sagt, dass der Rückgabetyp eine Ableitung vom Interface I sein muss.

Wenn eine Klasse ein Interface implementiert handelt es sich aber nicht um eine Ableitung, oder habe ich da was überhört???

Gruß

 

[faetzminator]

Ja genau, aber das musst du halt einfach im Konstruktor machen, was spricht dagegen?

 

[gee_20_4_7]

Ja genau, aber das musst du halt einfach im Konstruktor machen, was spricht dagegen?

Das habe ich probiert, da meckerte der Compiler, dass es sich um ein finales Attribut handelt...sollte den final-Modifier entfernen, aber dieser war schon längst entfernt...

Gruß

 

[faetzminator]

Wenn das mit dem Interface nicht funktioniert, dann versuchs mit einer astrakten Klasse

 

[gee_20_4_7]

Wenn das mit dem Interface nicht funktioniert, dann versuchs mit einer astrakten Klasse

Das wär dann schon sinnvoller denke ich auch, aber dann würde ich zuviel ändern müssen, und mir Feinde im Projekt machen . Aber nochmal vielen Dank für die schnellen Antworten.

Was sagst du zu der von mir angebotenen Variante? Sollte doch OK sein, oder?

Gruß

 

[faetzminator]

nunja, sie ist sicherlich nicht sooo schön, aber wenns funktioniert

 

[SchonWiederFred]

Vorsicht, das extends in den spitzen Klammern hat eine andere Bedeutung als das extends was Du sonst so kennst. <E extends I> bedeutet NICHT, dass E eine Subklasse einer Klasse I ist. Das extends heißt in diesem Zusammenhang viel mehr "E ist ein Subtyp von I".

 

[Lexi]

In diesem Zusammenhang heißt es einfach extends und implements.

 

[Landei]

Dumme Frage: Warum trennst du die Elemente nicht schon beim Einfügen?

Aus'm Kopp - ohneGewähr:

class Z {
   private Map<Class<? extends I>,List<I>> map = new HashMap <Class<? extends I>,List<I>>();

   public void add(I i) {
      Class<? extends I> clazz = i.getClass();
      List<I> list = map.get(clazz);
      if (list == null) {
          list = new ArryList<I>();
          map.put(clazz, list);
      } 
      list.add(i);
   }

   public List<I> getList(Class<? extends I> clazz) {
       return map.get(clazz);
   }
}

 

[Noctarius]

Ohne Scheiss die Idee ist klasse, wieso ist da keiner eher drauf gekommen *kopf vs. tisch*

 

[gee_20_4_7]

Also nochmal ein großes Danke an alle.
Verblüfft hat mich, dass extend in den eckigen Klammern beides heißt, aber ok, kann man sich merken. Die Variante von Landei ist der absolute Hammer -> Da muss man erstmal drauf kommen! Werde die Variante mal vorschlagen.
Jetzt würde ich gerne noch eines wissen wollen. Wie sieht es mit einer Implementation aus (denke, dass es sich immer um Casts handelt), die eine "Suppress Warning" fordert/wirft/ausgibt . Sollte man das vermeiden? Gibts da Möglichkeiten, drum herum zu kommen, oder kann man das stehen lassen, ohne vom "Chef" eins auf den Deckel zu bekommen?

 

[faetzminator]

Bei Arrays kommst du meistens nicht drum herum, da hat Sun irgendwas verbockt.

 

[Lexi]

Verblüfft hat mich, dass extend in den eckigen Klammern beides heißt, aber ok, kann man sich merken.

Da Generics erst später eingeführt worden sind, ich glaube mit Java 5, wollte sun die Kreation von neuen "Schüsselwörtern" ( oder wie man das nennt ) verhindern, damit man keinen alten Code kaputtmacht.

 

[gee_20_4_7]

OK, dann danke ich nochmal allen die mir hier helfend bei Seite standen!
Und deklariere wenn auch nur verbal, oder geht das hier irgendwie anders, den Thread als geschlossen.

THX a lot

 

[Noctarius]

btw noch einmal am Ende:
das extends steht nicht in eckigen Klammern "[]" sondern in spitzen Klammern "<>"

 

[gee_20_4_7]

Ups, hatte ich das geschrieben?

 

[Noctarius]

Ist ja nicht schlimm, wollts nur sicherheitshalber noch mal richtig stellen falls es mal irgendwann wer anders ließt =)

 

[Landei]

btw noch einmal am Ende:
das extends steht nicht in eckigen Klammern "[]" sondern in spitzen Klammern "<>"

Oder nimm Scala, da sind es wieder eckige Klammern []



(Das konnt' ich mir nicht verkneifen, hat zu gut gepaßt)

 

[Noctarius]

(Das konnt' ich mir nicht verkneifen, hat zu gut gepaßt)

hehe ^^