Downcast automatisch?

[alfons]

Hallo,

ist es irgendwie möglich Klassen automatisch heruntercasten?
Bsp.: Ich habe

class Person{ .. }
class Man extends Person { .. }
class Woman extends Person { .. }
class Child extends Person { .. }

class Foo {

  public void foo(){
    List<Person> persons = new ArrayList<Person>();
    persons.add(new Man());
    persons.add(new Woman());
    persons.add(new Child());
  }

}

Jetzt Möchte ich per persons.get(i); direkt auf da Man- oder Child-Objekt zugreifen. Hintergrund ist ein Webservice, der per JAXB die Transferdaten automatisch erzeugen soll und das möglichst erweiterbar. D.h. es wird davon ausgegangen, dass der Empfänger (im Frontend) eine Komponente bereitstellt, welche die Daten braucht und entsprechend verarbeiten kann.

 

[thewulf00]

Entweder sind die Methoden, die Du nutzt, schon in Person verfügbar, oder Du musst das Objekt per Hand casten.

 

[alfons]

Gibt es da keine andere Möglichkeit? Per Hand fällt aus, da der Service ja weitestegehnd vom Model gekapselt ist und das Model ja auch erweiterbar sein soll. Genauso kann ich nicht alle Methoden der Oberklasse zuweisen, da es sich zum Teil um komplett unterschiedliche Konzepte handelt.. ;(

 

[tfa]

sich zum Teil um komplett unterschiedliche Konzepte handelt

Komplett unterschiedliche Konzepte sollten man nicht in eine Klassenhierarchie packen. Wie soll der Compiler denn entscheiden, in welche Typen automatisch herunter gecastet werden kann? Das geht nicht, jedenfalls nicht in einer statisch typisierten Sprache.

 

[SlaterB]

du kannst mit Reflection Methodennamen als String vorgeben bzw. einfach eine Txt-Datei schreiben,
aber überlege doch mal, in kontrollierten Programmiersprachen müssen Klassen an sich und Typ von Objekten schon bekannt sein,
damit irgendwas zivilisiert funktioniert, alles andere ist Beliebigkeit

 

[Gast2]

Gibt es da keine andere Möglichkeit? Per Hand fällt aus, da der Service ja weitestegehnd vom Model gekapselt ist und das Model ja auch erweiterbar sein soll. Genauso kann ich nicht alle Methoden der Oberklasse zuweisen, da es sich zum Teil um komplett unterschiedliche Konzepte handelt.. ;(

Da gibts nur 2 Möglichkeiten:

Deine Person "Klasse" sollte zunächst ein Interface sein (oder im extremsten Fall eine abstrakte Basisklasse falls Funktionlität implementiert werden muss).

Weiter sollte Person ALLE Funktionalitäten vorgeben die der Dienst nutzen können soll!

Sollten deine konkreten Klassen aber Methoden haben, welche nicht in die Basisklasse/Interface zu implementeiren sind, dann hast du wahrscheinlich einen Fehler in der Klassenhierarchie gemacht.

Es gibt ein recht gutes OOP Buch von Galileo Press (Kostenlos als open book). Da stehen einige konzepte recht gut erklärt, wie man solche Klasssenhierarchien aufbaut. Bin nur jetzt zu faul den Link rauszusuchen.

 

[Gast2]

Komplett unterschiedliche Konzepte sollten man nicht in eine Klassenhierarchie packen. Wie soll der Compiler denn entscheiden, in welche Typen automatisch herunter gecastet werden kann? Das geht nicht, jedenfalls nicht in einer statisch typisierten Sprache.

Mit anderen Worten und etwas schneller als ich: Fehler in der Hierarchie

 

[thewulf00]

Also um den anderen Recht zu geben: Dein Klassenkonstrukt ist ein Problem.

Aber wenn Du unbedingt eine Lösung brauchst, dann mach es von außen:
[Java]Person obj = irgendwas.get(parameter);
if (obj.getClass() == Man.class) {
Man man = (Man)obj;
//doSmth();
}else if (obj.getClass() == Child.class) {
Child child = (Child)obj;
//doSmthElse();
}....[/Java]

 

[alfons]

OK..OK Danke.

Meine Intention war ja nicht mit den Objekten zu Arbeiten, sondern von diesen ja nur ein repräsentatives XML-Objekt zu erzeugen, mit dem die Komponente im Frontend etwas anfangen soll. Und da ich wie die meisten Menschen ziemlich faul bin, wollte ichs mir so einfach wie nur irgendwie möglich machen..

 

[thewulf00]

Und da ich wie die meisten Menschen ziemlich faul bin, wollte ichs mir so einfach wie nur irgendwie möglich machen..

Aber dabei unterstützt Dich doch die OOP! Mach in der Personklasse eine abstrakte Methode [c]getAsXML();[/c] und implementiere sie in allen Subklassen - fertig.

 

[faetzminator]

Also wenn du von JAXB sprichst, dann hast du da sowieso alles von [c]MarshallableRootElement[/c] geerbt. Diese Methoden musst du lediglich implementieren. Oder versteh ich dich da falsch?

 

[Landei]

Es gibt Datenstrukturen, in die man beliebig viele Daten beliebigen Typs packen kann, z.B. heterogene Listen. Das funktioniert auch in Java (siehe z.B. HList (Functional Java 3.0) und Heterogeneous Lists and the Limits of the Java Type System Apocalisp ), wird aber durch die exorbitanten Typsignaturen schnell furchtbar unpraktisch. Eventuell kann das der neue [c]<>[/c]-Operator ("diamond") in Java 7 etwas entschärfen (siehe dazu Diamonds are forever &ndash; der &ldquo;Diamant-Operator&rdquo; in Java 7 ).

 

[alfons]

Also wenn du von JAXB sprichst, dann hast du da sowieso alles von [c]MarshallableRootElement[/c] geerbt. Diese Methoden musst du lediglich implementieren. Oder versteh ich dich da falsch?

Ha ...ich glaube das war jetzt das richtige Stichwort

Ich habe mich bisher weder mit jersey noch mit JAXB so richtig auseinandergesetzt. Bisher hat es gereicht die Klassen mit @XMLRootElement zu annotieren (der Rest war dann pure Magie).

 

[Spacerat]

Aber wenn Du unbedingt eine Lösung brauchst, dann mach es von außen:
[Java]Person obj = irgendwas.get(parameter);
if (obj.getClass() == Man.class) {
Man man = (Man)obj;
//doSmth();
}else if (obj.getClass() == Child.class) {
Child child = (Child)obj;
//doSmthElse();
}....[/Java]

Na, na, na, na, na....
[Java]Person obj = irgendwas.get(parameter);
if (obj instanceof Man) {
Man man = (Man)obj;
//doSmth();
}else if (obj instanceof Child) {
Child child = (Child)obj;
//doSmthElse();
}....[/Java]

 

[faetzminator]

Ich habe mich bisher weder mit jersey noch mit JAXB so richtig auseinandergesetzt. Bisher hat es gereicht die Klassen mit @XMLRootElement zu annotieren (der Rest war dann pure Magie).

Ich kann dir ehrlich gesagt nicht sagen, wie dass das mit aktuellen Versionen funktioniert. Aber du wirst sicher mit @XMLRootElement auch die Klasse extenden und musst nur noch die Methoden überschreiben.
Wir verwenden eine wahrscheinlich 1000 Jahre alte Version in der Arbeit...

 

[thewulf00]

Na, na, na, na, na....
[Java]Person obj = irgendwas.get(parameter);
if (obj instanceof Man) {
Man man = (Man)obj;
//doSmth();
}else if (obj instanceof Child) {
Child child = (Child)obj;
//doSmthElse();
}....[/Java]

Verdammt! Bei dem ganzen Generics-Kram, den ich in letzter Zeit gemacht habe, hab ich die praktischen Dinge aus den Augen verloren - vielen Dank!

 

[Andi_CH]

Ein Zitat eines Dozenten: "...immer wenn in OO Programmen if-else oder switch-case auftauchen ist zu hinterfragen ob man das OO Konzept begriffen hat ..."

Das ist natürlich ein bisschen aus dem Zusammenhang gerissen und somit nicht generell zu verstehen, aber wenn eine Unterscheidung nach Typ vorkommt unterschreibe ich das sogar ;-)

 

[thewulf00]

Ein Zitat eines Dozenten: "...immer wenn in OO Programmen if-else oder switch-case auftauchen ist zu hinterfragen ob man das OO Konzept begriffen hat ..."

Das ist natürlich ein bisschen aus dem Zusammenhang gerissen und somit nicht generell zu verstehen, aber wenn eine Unterscheidung nach Typ vorkommt unterschreibe ich das sogar ;-)

Das ist eigentlich ne gute Regel, denn wie häufig kommt es vor, dass manche hier einen Quelltext posten und die Stammposter antworten, man habe das Klassenkonzept nicht verstanden...