Unterschied zwischen Polymorphie und Typcasting

[ChristianWalther]

Hallo, ich verstehe nicht was der Unterschied zwischen Polymorphie mit verschiedenen Sichten auf das Objekt und dem Casting von Objekten ist. Beispiel:

Hier ein skizziertes Beispiel indem es die Superklasse Mitarbeiter gibt von der die Klasse Fuehrungsperson erbt.

public class Mitarbeiter {
private String Name;
private int Alter;

public String getName() {
.... 
}

public int getAlter() {
.... 
}
}

public class Fuehrungsperson extends Mitarbeiter {
private String Dienstwagen;

public String getDienstwagen() {
.... 
}
}

So, und nun habe ich folgenden Code:

Fuehrungsperson f1 = new Fuehrungsperson();
Mitarbeiter m1 = null;
m1 = f1;
m1.getDienstwagen // geht natürlich nicht, weil wir f1 nun als Mitarbeiter betrachten!
f1 = (Fuehrungsperson) f1; // f1 ist nun wieder Führunskraft
//Alternativ hätte ich nun aber auch machen können
Fuehrungsperson f2 = f1; //f1 ist nun ebenfalls wieder Führungskraft und getDienstwagen funktioniert wieder

Was bringt mir nun das Casting im Gegensatz zu einer normalen Deklaration bzw wo ist der Unterschied zwischen den Sichtweisen und einem expliziten Cast?

Hoffe, dass war irgendwie verständlich ...

 

[hdi]

[HIGHLIGHT="Java"]f1 = (Fuehrungsperson) f1; // f1 ist nun wieder Führunskraft[/HIGHLIGHT]

...das war es immer! Was du in m1 speicherst hat nichts mit f1 zu tun.
Der Cast in o.g. Code, also die komplette Zeile, änder nichts am Programm.
Du machst aus einer Führungsperson eine Führungsperson und weist sie
der Variablen zu, die schon davor genau diese Referenz hatte.

Ich glaube du hast dich da vertippt, kann das sein? Deine Frage zielt wohl eher
auf das m1 ab, oder?

Wenn ja, bitte nochmal mit dem, was grad wirklich dein Problem ist.

 

[Wildcard]

casten versucht man nach Möglichkeit zu vermeiden. In der Regel versucht man bei der deklaration eines Typs so weit nach unten zu gehen wie sinnvoll.
Das sieht man zB sehr gut am Beispiel von Collections. Oft braucht man zB nicht mehr, als die Methoden die das Interface Collection anbietet.
Es gibt also keinen Grund überall im Code die Information durchzuschleifen, das es sich eigentlich um zB eine LinkedList handelt.
Also statt LinkedList stuff = new LinkedList() lieber ein Collection stuff = new LinkedList(), oder List stuff = new LinkedList().
Auf diese weise kannst du später problemlos auf eine ArrayList, oder ein HashSet umstellen und musst nur eine Zeile ändern.

 

[Marco13]

Hallo, ich verstehe nicht was der Unterschied zwischen Polymorphie mit verschiedenen Sichten auf das Objekt und dem Casting von Objekten ist.
...
Was bringt mir nun das Casting im Gegensatz zu einer normalen Deklaration bzw wo ist der Unterschied zwischen den Sichtweisen und einem expliziten Cast?

Den Code müßtest du noch ein bißchen genauer Erklären, aber auf die allgemeine Frage eine allgemeine Antwort:

Casten (von Objekten) benutzt man, um ein Objekt mit einem bestimmten Typ auch genau als solchen Ansprechen zu können. In Anlehnung an dein Beispiel:

[HIGHLIGHT="Java"]
Mitarbeiter m = new Fuehrungsperson();
m.getDienstwagen(); // Geht nicht: Ein Mitarbeiter hat keinen Dienstwagen

// Hier der cast: Ich WEISS, dass "m" eine Führungsperson ist,
// und will "m" deswegen auch als Führungsperson verwenden können:
Fuehrungsperson f = (Fuehrungsperson)m;
f.getDienstwagen(); // Geht jetzt
[/HIGHLIGHT]


Polymorphie bringt dann etwas, wenn es um Objekte geht, die die gleiche Schnittstelle haben, aber unterschiedliche Implementierungen, d.h. (vereinfacht) wenn zwei Klassen die gleiche Methode haben, die Methoden aber in beiden Klassen unterschiedliche Sachen machen - als Beispiel eine Methode "getGehalt":
[HIGHLIGHT="Java"]
Mitarbeiter m0 = getMitarbeiter(0);
Mitarbeiter m1 = getMitarbeiter(1);

System.out.println(m0.getGehalt()); // Gibt 1000 aus
System.out.println(m1.getGehalt()); // Gibt 5000000 aus
[/HIGHLIGHT]

Die beiden objekte (m0 und m1) sind jeweils Mitarbeiter. EINER von beiden ist auch eine Führungsperson (welcher wohl? ), aber das ist hinter dem polymorphen Aufruf von "getGehalt", der für ALLE Mitarbeiter verfügbar ist, versteckt...


EDIT: Ich merke gerade, dass das Beispiel nicht wirklich geeignet ist, um den Vorteil (und die Mächtigkeit) von Polymorphie zu verdeutlichen: getGehalt könnte ja auch einfach einen int zurückgeben, der für beide unterschiedlich gesetzt ist. Der Vorteil ist, dass die Implementierung wirklich komplett unterschiedlich sein kann. Ein anderes Beispiel:
[HIGHLIGHT="Java"]
class Mensch
{
void kaufeSchuhe()
{
geheIn(nächstgelegerLaden());
for (Schuhe schuhe : nächstgelegerLaden().getSchuhe())
{
if (passen(schuhe))
{
kaufe(schuhe);
return;
}
}
}
}

class Frau extends Mensch
{
void kaufeSchuhe()
{
for (Laden laden : alleLädenDerStadt())
{
geheIn(laden);
for (Schuhe schuhe : laden.getSchuhe())
{
if ( // passen(schuhe) // egal
sindSchick(schuhe) && sindTeuer(schuhe) && sindModern(schuhe))
{
kaufe(schuhe);

//return; // Kein return hier...
}
}
}
}
}
[/HIGHLIGHT]

 

[ChristianWalther]

Also schonmal Danke für die Antworten !
Das Problem ist, dass ich das Thema in der Uni habe und es bisher nur theoretisch ist, also einen konkreten Fall wo ich das brauche habe ich nicht, daher habe ich diesen sehr simplen (und nicht sonderlich sinnvollen) Fall eben konstruiert.

Mir ist momentan einfach nicht klar, wann ich einen Typcast bei einem Objekt verwende und warum ich das tun sollte.

Wenn ich ein Fuehrungsperson Objekt habe und vielleicht eine Methode:

public String getSteuernummer(Mitarbeiter m) {
return m.Steuernummer;
}

und schließlich getSteuernummer(Fuehrungsperson) aufrufe, dann habe ich ja für diese Zeit eine "Mitarbeiter" Sicht auf das Objekt, was jedoch in wirklichkeit eine Führungsperson ist - da aber nun alle Mitarbeiter (und damit alle abgeleiteten Klassen) eine Steuernummer haben, ist dies ja kein Problem und meine Methode Steuernummer ist für alle Unterklassen von Mitarbeiter nutzbar (hier liegt doch der Sinn der Polymorphie?!).

Wann soll ich aber nun einen Typcast verwenden ?!

In diesem Fall wäre doch der einzig sinnvolle Grund, wenn ich nun in der Funktion aus irgendeinem Grund vielleicht doch eine Spezialfunktion der Führungsperson nutzen will und dann z.b. mache:

Fuehrungsperson f = (Fuehrungsperson) m;

D.h. doch praktisch, dass ich einen Cast nur dann benutze, wenn ich vorher ein Objekt in einen übergeordneten Statischen Typ gesteckt habe? (Das Objekt also verallgemeinert habe?)

 

[Wildcard]

D.h. doch praktisch, dass ich einen Cast nur dann benutze, wenn ich vorher ein Objekt in einen übergeordneten Statischen Typ gesteckt habe? (Das Objekt also verallgemeinert habe?)

Ja, mit einer ausnahme. Es gibt auch den downcast, das ist aber eher ein Speziallfall.
Wenn du zwei Methoden hast:
[HIGHLIGHT="Java"]
doSomethingWith(Mitarbeiter m){
System.out.println("Foo");
}
doSomethingWith(Fuehrungsperson p){
System.out.println("Bar");
}[/HIGHLIGHT]
Nun hast du folgendes;
[HIGHLIGHT="Java"]Fuehrungsperson p = new Fuehrungsperson();
doSomethingWith(p); //gibt Bar aus
doSomethingWith((Mitarbeiter)p); //gibt Foo aus[/HIGHLIGHT]
Das ist die einzige Auswirkung die ein cast auf die Runtime hat.
Liegt daran, das Java eine Single Dispatch Sprache ist, aber wie gesagt, das ist eher ein Spezialfall. Normalerweise castest du auf einen konkreteren Typ.

 

[hdi]

Also erstmal:

[HIGHLIGHT="Java"]public String getSteuernummer(Mitarbeiter m) {
return m.Steuernummer;
}[/HIGHLIGHT]

ist Unsinn. Das ist eine nicht-statische Methode. Solche Methoden geben
Infos über das Objekt, auf dem sie aufgerufen werden, zurück. Und nicht
über irgendeinen anderen Mitarbeiter.

D.h. deine Methode hier würde nur statisch Sinn machen, aber dann kannste
Polymorphie wegwerfen, wenn du keine nicht-statische Version davon hast,
die ein echter Getter ist:

[HIGHLIGHT="Java"]public String getSteuernummer(){
return this.getSteuerNummer();
}[/HIGHLIGHT]

Fragen wir mal so: Ist dir der Unterschied zwischen statisch und nicht-statisch bewusst?
Denn das muss man in allererster Instanz verstanden haben, bevor man mit Polymorphie
usw. anfängt.

Was das casten betrifft: Ich glaube du machst dir hier ein Problem, dass es gar nicht gibt.
Die Frage hört sich für mich so an wie:

"Warum sollte ich 4+4 schreiben statt 2*4"?

Also... wenn du casten willst, mach halt. Aber wieso bringst du dich überhaupt in eine
Situation, wo du das musst? Das vermeidet man, wie schon von einem Vorredner gesagt.

...klären wir erstmal das (non-)static Ding!

 

[ChristianWalther]

@Wildcard: Ah alles, klar - habe verstanden

@hdi
Ja das mit statischer und nicht-statischer Methode ist klar.
Eine statische Methode brauch, im Gegensatz zu einer nicht-statischen, keine Instanz der aktuellen Klasse.

Das Beispeil war nicht gut gewählt, ich wollte damit das gleiche zeigen wie Wildcard ein Post unter meinem, um zu verdeutlichen, dass in der Methode eben (je nach Input) ein Upcast auf Mitarbeiter erfolgt.

Was das casten betrifft: Ich glaube du machst dir hier ein Problem, dass es gar nicht gibt.

Das kann gut sein, ich sehe halt (mit meinem geringen Programmierwissen) keinen praktischen Grund, warum ich eine Funktion etc so designen sollte, dass ich Casten muss.

Ich würde bei Funktionen, bei denen ich aus irgendwelchen Gründen in einer Subklasse eine Spezifizierung brauche (z.b. soll ein weiteres Attribut der Subklasse beachtet werden) die Methode einfach überschreiben (mit passendem Übergabeparamter für die Subklasse). Anstatt beispielsweise in der Supermethode mit "instanceof" die passende Ausführung rauszusuchen und das Objekt umzucasten.

Also ich denke ich hab das mit dem (Up und Down)Casten so weit verstanden - vielen Dank

Wenn noch jemand was allgemeines zum Casten bzw warum man es in der Praxis tatsächlich tun sollte schreiben möchte, lese ich natürlich gerne weiter :toll:

 

[hdi]

Das kann gut sein, ich sehe halt (mit meinem geringen Programmierwissen) keinen praktischen Grund, warum ich eine Funktion etc so designen sollte, dass ich Casten muss.

Und genau so macht man das auch in gutem Design!

Ich würde bei Funktionen, bei denen ich aus irgendwelchen Gründen in einer Subklasse eine Spezifizierung brauche (z.b. soll ein weiteres Attribut der Subklasse beachtet werden) die Methode einfach überschreiben (mit passendem Übergabeparamter für die Subklasse). Anstatt beispielsweise in der Supermethode mit "instanceof" die passende Ausführung rauszusuchen und das Objekt umzucasten.

Und genau das ist Polymorphie, und auch das macht man so wie du sagst!

Du hast das schon alles verstanden, mach dich nich verrückt mit dem Casten
Wird halt angeboten, wenn man es im Design verschissen hat, um sich noch zu retten.
Umso besser, wenn man es ohne Cast lösen kann

 

[Wildcard]

Ich würde bei Funktionen, bei denen ich aus irgendwelchen Gründen in einer Subklasse eine Spezifizierung brauche (z.b. soll ein weiteres Attribut der Subklasse beachtet werden) die Methode einfach überschreiben (mit passendem Übergabeparamter für die Subklasse). Anstatt beispielsweise in der Supermethode mit "instanceof" die passende Ausführung rauszusuchen und das Objekt umzucasten.

casten ist mehr der Notnagel, wenn eine saubere Lösung nur sehr umständlich umsetzbar ist. Es gibt allerdings schon einige wenige echte Anwendungsfälle. Zum Beispiel liefert dir ein ObjectInputStream ein generisches Object und du musst i.d.R. casten um damit etwas anfangen zu können.

 

[ChristianWalther]

Okay - ich danke euch allen für die Hilfe

Da hatte ich ja zumindest doch nicht alles falsch verstanden und mich nur unnötig auf zwanghaftes Casten eingeschossen.