Cast vermeiden

[Mortal_Shadow]

Hi,

ich stehe vor folgendem Problem.
Meiner Methode wird ein Objekt einer Basisklasse übergeben.
Je nach Subklasse, will ich es jedoch anders behandeln.
Momentan sieht mein Code dabei so aus:

if(info.getClass() == InfoPosChange.class){
			@SuppressWarnings("unused")
			InfoPosChange i = (InfoPosChange) info;
                                  //tu was mit i
		}

Wegen dem SupressWarnings gefällt mir das allerdings nicht so.
Geht das auch sauberer, oder muss ich das so lassen?

Danke im vorraus.

 

[maki]

Meiner Methode wird ein Objekt einer Basisklasse übergeben.
Je nach Subklasse, will ich es jedoch anders behandeln.

Der fett markierte Satz ist dein Problem

Was genau willst du denn anders behandeln?

 

[Noctarius]

Ohne Cast geht nur mit Reflection Aber was ist an dem Cast so schlimm?

Alternativ kannst du dir eine Cast-Helper-Methode machen.

public static <T> T cast(Object object) {
  return (T) object;
}

 

[eRaaaa]

Wegen dem SupressWarnings gefällt mir das allerdings nicht so.

Was hat denn jetzt die SupressWarnings mit dem Cast zu tun in diesem Fall? Sobald du irgendwann dein i auch mal lesend benutzt, brauchst du die doch auch nicht mehr? Oder raff ich`s gerade nicht?

 

[Noctarius]

PS: Mach lieber einen InstanceOf Vergleich

if(info.getClass() == InfoPosChange.class)

if(info instanceof InfoPosChange)

 

[Murray]

1. Was hat SuppressWarning("unused") denn mit dem Cast zu tun?

2. Ist es Absicht, dass du

if(info.getClass() == InfoPosChange.class){

schreibst und nicht

if(info instanceof InfoPosChange){

?

 

[0x7F800000]

public static <T> T cast(Object object) {
  return (T) object;
}

Hö? Was ist das denn? Woher soll die methode wissen, was T ist? Wieso lässt mein Compiler das durchgehen?! Und vor allem: wozu soll das gut sein, der Compiler tut so, als ob T einfach Object wäre, wenn man die Methode aufruft ???:L

 

[Mortal_Shadow]

t.t
Mir ist gerade etwas aufgefallen:
@SuppressWarnings("unused")
Ich wollte das sauberer machen, da ansonsten diese Warung kam.
(Wie eraa grad gepostet hat, ist das aber keine Typ-unsafety warnung)
Ich sollte erst denken dann posten....
Danke auf jedenfall für die Hilfe, ging ja saumäßig schnell.

Ps: Danke für den insatnceof-tipp.

 

[Noctarius]

Hö? Was ist das denn? Woher soll die methode wissen, was T ist? Wieso lässt mein Compiler das durchgehen?! Und vor allem: wozu soll das gut sein, der Compiler tut so, als ob T einfach Object wäre, wenn man die Methode aufruft ???:L

Weil der Compiler dann den Typ T zur Compilezeit anhand des Types der Variable, in welcher das Result gespeichert wird, festlegt. Er geht dann einfach davon aus, dass der Programmierer schon sicher weiß das es geht. Wenn's trotzdem nicht passt fliegt eine ClassCastException.

String foo = cast("foo");
Integer foo = cast(15);

Ich kann auf diese Weise auch einige andere Dinge sicherstellen

public static <T> T newInstance(Class<T> clazz) { return (T) clazz.newInstance(); }

String foo = newInstance(String.class); // geht
String foo2 = newInstance(Integer.class); // geht nicht

Z.B. hier auf Zeile 62:
https://code.google.com/p/javaxmlpa...ourceprojects/xmlparser/XmlParserFactory.java

 

[0x7F800000]

Weil der Compiler dann den Typ T zur Compilezeit anhand des Types der Variable, in welcher das Result gespeichert wird, festlegt. Er geht dann einfach davon aus, dass der Programmierer schon sicher weiß das es geht. Wenn's trotzdem nicht passt fliegt eine ClassCastException.

Ähm... An zehn tausend milliarden stellen schreibt man die typen immer doppelt und dreifach, und ausgerechnet für irgendwelchen casting-quatsch ist Typinferenz aktiviert? Was zum Teufel...

class C{
	public static <T> T cast(Object o){
		return (T)o;
	}
	
	public static void foo(String s){
		
	}
	
	{
		String s = cast(2345);	//dieser quatsch geht
		foo(cast(2345));		//dieser quatsch geht nicht
	}
}

Gibt es dafür irgeneine sinnvolle Anwendung, die nicht nur zum Schmeißen von ClassCastExceptions gut ist? ???:L

Manoman, man lernt doch nie aus... :noe:

 

[Noctarius]

Siehe den Factory-Code von mir oben. Ja gibt es (für die JVM gibt es eh nur Objects).

Das zweite geht nicht, weil dort keine Zuweisung an eine Variable stattfindet und somit kein Typ definiert ist. Das zweite legt das Ergebnis nur auf den Stack.

edit: Wird sogar in der JRE genutzt

 

[Noctarius]

Als Nachtrag, hier die Stelle im JLS:

Names

The scope of a method's type parameter is the entire declaration of the method, including the type parameter section itself. Therefore, type parameters can appear as parts of their own bounds, or as bounds of other type parameters declared in the same section.