Ersatz fuer instanceof

[MiMij]

Also ich hab nen Vector mit Objecten.
Menutyp1, Menutyp2 und Menutyp3
2 und 3 erben von 1
jetzt hab ich das mit instanceof geloest

Object o = menuTypen.elementAt(currentChooseNumber-1);
		if ( o instanceof MenuType2 ) {
			Display.getDisplay(main).setCurrent((MenuType2)menuTypen.elementAt(currentChooseNumber-1));
		} else if ( o instanceof MenuType1 ) {
			Display.getDisplay(main).setCurrent((MenuType1)menuTypen.elementAt(currentChooseNumber-1));
		}

Gibts da ne bessere Loesung? Weil ich mal gelesen hab, man sollte den Gebrauch von instanceof vermeiden.[/code]

 

[Guest]

Wenn Typ 2 und Typ 3 von Typ 1 erben und deine Methode (Display.getDisplay(main).setCurrent() anscheinend
Typ 1 akzeptiert, kannst du dir die Unterscheidung sparen.

Object o = menuTypen.elementAt(currentChooseNumber-1);
if ( o instanceof MenuType1 )
{
   Display.getDisplay(main).setCurrent((MenuType1)o);
}

Weil ich mal gelesen hab, man sollte den Gebrauch von instanceof vermeiden.

In der Bildzeitung? :wink:
Es spricht nichts dagegen, vorhandene Sprachkonstrukte zu verwenden.

 

[byte]

Definiere die gemeinsame Schnittstelle aller Menutypen in einem Interface. Dann brauchst Du nicht mehr zu unterscheiden, welcher Menutyp vorliegt sondern brauchst nur noch auf dem Interface arbeiten.

Ansonsten:
Alternative zu instanceof ist o.getClass() == Menutyp1 😉

 

[MiMij]

@Gast
Ok, danke. Funktioniert. Irgendwie hatte ich das vorher probiert, aber das lief net richtig. Aber da war wohl noch nen anderer Fehler und darum lief es wohl net 😀

 

[Marco13]

Weil ich mal gelesen hab, man sollte den Gebrauch von instanceof vermeiden.

In der Bildzeitung? :wink:
Es spricht nichts dagegen, vorhandene Sprachkonstrukte zu verwenden.

:autsch: Abgesehen davon, dass 'instacneof' immer eine Kapitulation vor der Objektorientierung ist, und die übermäßige Verwendeung ("um sich das Leben leichter zu machen") früher oder später dazu führt, dass die Programme nicht mehr so gut erweiterbar sind, wie sie sein sollten...

Um die Frage also zu beantworten: Der "Ersatz für instanceof" heißt "Polymorphie" :meld:
http://de.wikipedia.org/wiki/Polymorphie_(Programmierung)

 

[Guest]

...:autsch: Abgesehen davon, dass 'instacneof' immer eine Kapitulation vor der Objektorientierung ist, und die übermäßige Verwendeung ("um sich das Leben leichter zu machen") früher oder später dazu führt, dass die Programme nicht mehr so gut erweiterbar sind, wie sie sein sollten...

Ist ja gut.

:lol:

Wenn man aber eine API verwendet, die einfach nur Object als Ergebnis liefert und die Anzahl möglicher Typen
beschränkt ist (und auch bleibt), macht es keinen Sinn eine Doktorarbeit daraus zu machen.
Ich habe schon oft Projekte erlebt, wo die Entwickler alles auf Teufel komm raus "Wiederverwendbar" machen
wollten, ohne daran zu denken, dass es für eine Erweiterung nicht vorgesehen ist und wenn, dann nicht auf
einem solch niedrigen Level. Das Ergebnis ist dann ein Irrwitziges Framework, bei dem keiner mehr durchblickt.
Recht hast du trotzdem. Wenn sich sowas vermeiden lässt, vermeidet man es einfach.

 

[byte]

Es gibt halt die einen, die alles so zurechtschrauben dass es funktioniert. Und dann gibts halt noch die anderen, die es richtig machen. :roll: Alles eine Frage der Erfahrung.

 

[Beni]

Es gibt halt die einen, die alles so zurechtschrauben dass es funktioniert. Und dann gibts halt noch die anderen, die es richtig machen. :roll: Alles eine Frage der Erfahrung.

:lol: :toll:

 

[André Uhres]

Nur zur Information: "instanceof" ist keine Kapitulation, sondern ein Operator.
java.lang.Class#isInstance ist dagegen eine Methode,
genauso wie java.beans.Beans.isInstanceOf oder java.beans.Beans.getInstanceOf

 

[Marco13]

Naja - ohne zu wissen, was du genau meintest - es gibt Stellen, an denen es "absichtlich" eingesetzt wird, eben gerade um nicht alles über Polymorphie lösen zu müssen. Aber das sind Spezialfälle. In "normalem" Code kann man jedes instanceof durch Polymorphie ersetzen. An einigen Stellen "sollte" man das auch nicht machen, weil es einfach ein krampfiger Overkill wäre. In diesem Fall aber vermutlich nicht...

 

[André Uhres]

Naja - ohne zu wissen, was du genau meintest - es gibt Stellen, an denen es "absichtlich" eingesetzt wird, eben gerade um nicht alles über Polymorphie lösen zu müssen. Aber das sind Spezialfälle. In "normalem" Code kann man jedes instanceof durch Polymorphie ersetzen. An einigen Stellen "sollte" man das auch nicht machen, weil es einfach ein krampfiger Overkill wäre. In diesem Fall aber vermutlich nicht...

Sehr diplomatisch. Ich denke, so kann ich das unterschreiben 😀

 

[MiMij]

Danke danke 😀
Habs jetzt ohne instanceof geloest 😀
In dem Vector ist ja eig alles vom typ menutyp1 weil 2 und 3 ja von 1 erben
also:

Display.getDisplay(main).setCurrent((MenuType1)menuTypen.elementAt(currentChooseNumber));