Schnittstellen und Objekte in komplizierter Form

[edgrar_u]

Hi,


ich schlag mich grad mit Objekten und Schnittstellen rum und es wird langsam kompliziert.

Ich hab eine Methode die folgendes zurückgibt :
return (Object) new Textpassage (new String(tmp));

Textpassage ist eine Klasse mit einem einzigen Feld : String text
tmp ist ein Array mit chars das text hilft das Feld Text zu bearbeiten


Also ich denke mal es wird ein Objekt zurückgegeben. tmp das char Array wird in einen String umgewandelt , das ganze wird daann in Textpassage umgewandelt und in ein Object gecastet. Aber wo ist das eigentliche Objekt das zurückgegeben werden soll? tmp ist doch nur der Parameter von String und String der Parameter von textpassage. tmp wird praktisch dem Konstruktor von Textpassage zugewiesen und in dessen String text geschrieben. :bahnhof:
Warum muss man tmp erst in einen String , in eine Textpassage ,und dann das ganze in ein Obj. casten ?? Kann man das Array nich gleich in ein Objekt casten? ???:L :bahnhof:

Also ich kapier das ganze nicht.

Was ich auch nich versteh warum der Autor :

obj1 = (Comparable) param
ein Objekt in eine Schnittstelle castet ?? Warum , wie geht das ?? Was hat man davon , Schnittstellen sind doch nur leere Hüllen . ???:L

 

[Guest]

Der cast zu Object ist unnötig, sonst kann es verschiedene Gründe haben.

Textpassage (was auch immer es sein mag) bietet vielleicht paar Methoden
zur Manipulation des übergebenen Strings.
Vielleicht wird an irgendeiner Stelle ein Textpassage Objekt erwartet,
so dass du nicht einfach char-Array nehmen kannst.
z.B.

Textpassage tp = (Textpassage)obj; // irgendwo im Code

Bei char-Array ergäbe dies ClassCastException.

 

[0xdeadbeef]

Hi,


ich schlag mich grad mit Objekten und Schnittstellen rum und es wird langsam kompliziert.

Ich hab eine Methode die folgendes zurückgibt :
return (Object) new Textpassage (new String(tmp));

Textpassage ist eine Klasse mit einem einzigen Feld : String text
tmp ist ein Array mit chars das text hilft das Feld Text zu bearbeiten


Also ich denke mal es wird ein Objekt zurückgegeben. tmp das char Array wird in einen String umgewandelt , das ganze wird daann in Textpassage umgewandelt und in ein Object gecastet.

new String(tmp) erzeugt ein neues String-Objekt aus einem char-Array. Diese neue Objekt wird als Parameter des Konstruktors von Textpassage übergeben. Daraus wird ein neues Objekt vom Typ Textpassage. Das darf nach Object gecastet werden, weil jedes Objekt von Object abgeleitet ist.

Aber wo ist das eigentliche Objekt das zurückgegeben werden soll? tmp ist doch nur der Parameter von String und String der Parameter von textpassage. tmp wird praktisch dem Konstruktor von Textpassage zugewiesen und in dessen String text geschrieben. :bahnhof:

Zurückgegeben wird eine Instanz von Textpassage, die allerdings - aus Gründen, die hier nicht ohne weiteres ersichtlich sind - auf Object gecastet wurde.

Warum muss man tmp erst in einen String , in eine Textpassage ,und dann das ganze in ein Obj. casten ?? Kann man das Array nich gleich in ein Objekt casten? ???:L :bahnhof:

Arrays sind ebenfalls Objekte, könnten also auch in Object gecastet werden, aber das ist nicht Sinn der Übung. Es gibt hier nur einen Cast, nämlich "(Object)", alles andere sind neu erzeugte Objekte.
Die temporäre ERzeugung des String-Objekts ist vermutlich nur deshalb notwendig, weil es für Textpassage keinen Konstruktor für ein Char-Array gibt, sondern nur für String.

Was ich auch nich versteh warum der Autor :

obj1 = (Comparable) param
ein Objekt in eine Schnittstelle castet ?? Warum , wie geht das ?? Was hat man davon , Schnittstellen sind doch nur leere Hüllen . ???:L

Man kann zwar aus Interfaces keine Objekte bilden, aber sie sehr wohl als geforderte Parametertypen einer Funktion (Interfaces!!!) benutzen. Insofern ist der Cast auf ein Interface genauso sinnvoll wie der Cast auf ein hierarchisch höheres (also näher bei Object liegendes) Objekt.

 

[edgrar_u]

vielen dank für die Antworten.

Und vielen Dank für die Mühe die du dir gemacht hast Oxdeadbeaf. :toll: Was ich jetzt noch nich ganz verstanden hab. Castet man Objekte nur in schnittstellen um sicherzugehen das die Objekte die Schnittstellen implementieren?

Grüsse edgrar

 

[Beni]

Also eigentlich castet man gar nie, wenn man das Programm sauber aufgebaut hat :wink:

Wenn dochmal castet, dann castet man, um die Methoden aufzurufen. Du kannst bei einem Object nicht "meineUltraspezielleMethode()" aufrufen, weil Object diese Methode nicht besitzt.

 

[0xdeadbeef]

Also eigentlich castet man gar nie, wenn man das Programm sauber aufgebaut hat :wink:

Wenn dochmal castet, dann castet man, um die Methoden aufzurufen. Du kannst bei einem Object nicht "meineUltraspezielleMethode()" aufrufen, weil Object diese Methode nicht besitzt.

Mit Verlaub, aber das ist Quatsch.

Zum einen ist man ist Java 1.4 pausenlos genötigt zu casten, nämlich dann, wenn man Objekte aus Collections usw. holt.

Zweitens gilt es als gutes Design, eine möglichst hohe Abstraktion eines Objekts zu benutzen, also List statt ArrayList o.ä., damit man später nicht im ganzen Programm ändern muß, weil man statt ArrayList eine LinkedList verwenden will.
Dazu muß man aber nach der Erzeugung des spezialisierten Objekts (z.B. ArrayList) auf die abstraktere Klasse bzw. das Interface casten.

Drittens kann man in aller Regel nicht einfach casten, wenn eine Objektmethode einen anderen Typ verlangt, als den, den man gerade zur Verfüfung hat. Der gepostete Quellcode ist ein klassisches Beispiel dafür, daß man dann eben nicht casten kann, sondern sich temporär passende Objekte erzeugen muß.

 

[0xdeadbeef]

Was ich jetzt noch nich ganz verstanden hab. Castet man Objekte nur in schnittstellen um sicherzugehen das die Objekte die Schnittstellen implementieren?

Sagen wir mal so: Wenn man eine Objektmethode hat, deren Parameter nur solche Objekte zulassen soll, die eine Schnittstelle implementieren, dann ist es seitens der Methode sinnvoll, als Parameter eben dieses Interface zu definieren.

Derjenige, der diese Methode aufruft, muß sein Objekt dazu nicht zwangsweise casten, denn daß es die Schnittstelle implementiert, weiß der Compiler auch so.

Wenn allerdings im weiteren Verlauf keine speziellen Methoden des Objekts mehr gerufen werden, sondern nur noch die, die die Schnittstelle vorgibt, kann es sinnvoll sein, dafür eine Objektvariable vom Typ des Interfaces zu benutzen.
Das läßt wie schon in der anderen Antwort beschrieben, die Möglichkeit offen, später eine Instanz eines anderen Objekts zu verwenden, das ebenfalls die Schnittstelle implementiert.

Wie gesagt: in der Regel gilt es als gutes Design, wenn man immer den höchstnöglichen Abstraktionsgrad einer Klasse benutzt, also im Zweifelsfall auch eine abstrakte Klasse bzw. ein Interface. In Eclipse gibt es dazu auch eine Refakturisierungsfunktion namens "Use Supertype if possible" (o.ä.).

Ist allerdings ein zweischneidiges Schwert, weil es ja sehr wohl auch sein kann, daß man später doch noch eine spezielle Objektmethode braucht, die nicht durch das Interface vorgegeben bzw. Teil der "Überklasse" ist.

 

[Roar]

Also eigentlich castet man gar nie, wenn man das Programm sauber aufgebaut hat :wink:

Wenn dochmal castet, dann castet man, um die Methoden aufzurufen. Du kannst bei einem Object nicht "meineUltraspezielleMethode()" aufrufen, weil Object diese Methode nicht besitzt.

Mit Verlaub, aber das ist Quatsch.

Zum einen ist man ist Java 1.4 pausenlos genötigt zu casten, nämlich dann, wenn man Objekte aus Collections usw. holt.

Zweitens gilt es als gutes Design, eine möglichst hohe Abstraktion eines Objekts zu benutzen, also List statt ArrayList o.ä., damit man später nicht im ganzen Programm ändern muß, weil man statt ArrayList eine LinkedList verwenden will.
Dazu muß man aber nach der Erzeugung des spezialisierten Objekts (z.B. ArrayList) auf die abstraktere Klasse bzw. das Interface casten.

Drittens kann man in aller Regel nicht einfach casten, wenn eine Objektmethode einen anderen Typ verlangt, als den, den man gerade zur Verfüfung hat. Der gepostete Quellcode ist ein klassisches Beispiel dafür, daß man dann eben nicht casten kann, sondern sich temporär passende Objekte erzeugen muß.

1 is klar
2 aber nicht. wo musst du denn da bitte casten? List l = (List) new ArrayList(); is ja genauso sinnlos wie der "cast" auf Object im 1. post. ich geh sogar mal frech wie ich bin davon aus, dass das vom compiler verschluckt wird. wenn man später im programm irgendwann mal tatsächloich eine ArrayList braucht muss man natürlich casten, doch das wär auch ziemlich dumm, da 1. in dem beispiel mist list und arraylist, arraylist nix bietet was list nicht bietet, und 2. man dann auch direkt ArrayList nehmen kann, oder sogar muss wenn man arraylist braucht

 

[Beni]

Zum einen ist man ist Java 1.4 pausenlos genötigt zu casten, nämlich dann, wenn man Objekte aus Collections usw. holt.

Jo, wenn du natürlich eine schon seit Monaten veraltete Version benutzt...

Zweitens gilt es als gutes Design, eine möglichst hohe Abstraktion eines Objekts zu benutzen, also List statt ArrayList o.ä., damit man später nicht im ganzen Programm ändern muß, weil man statt ArrayList eine LinkedList verwenden will.
Dazu muß man aber nach der Erzeugung des spezialisierten Objekts (z.B. ArrayList) auf die abstraktere Klasse bzw. das Interface casten.

String blupp = "123";
Objct bla = blupp;  //*

* Das meinst du? Aber solche impliziten Casts sind ja nicht das Problem. edgar ging es garantiert um die Expliziten (nur dass er noch nicht weiss, dass man *nie* auf Object (explizit) casten muss).

Drittens kann man in aller Regel nicht einfach casten, wenn eine Objektmethode einen anderen Typ verlangt, als den, den man gerade zur Verfüfung hat. Der gepostete Quellcode ist ein klassisches Beispiel dafür, daß man dann eben nicht casten kann, sondern sich temporär passende Objekte erzeugen muß.

Jo klar. Dass man ein Auto nicht in einen Baum casten kann, dürfte auch edgar verstanden haben (schon bevor er hierher kam) :wink:

 

[0xdeadbeef]

Ihr habt natürlich recht, man muß nicht casten, wenn man in Richtung höherer Abtraktion zuweist. Ich mache es aus Gewohnheit trotzdem immer.

Ich persönlich kann auch nichts Schlimmes an der Benutzung von Casts finden. Ganz im Gegenteil: sie zeugen davon, daß man sich Gedanken gemacht hat.
In C beispielsweise muß man in sicherheitskritischen Bereichen (z.B. MISRA-Spezifikation für Automotive-Bereich) so ziemlich alles explizit casten, weil dann auf den ersten Blick klar ist, was passiert. Wenn man unter C/C++ Tools wie Lint benutzt, wird man ebenfalls zum Casten gezwungen.

Um aber nochmal ein Beispiel für einen notwendigen Cast zu bringen:

byte b = 0xff;  
byte a = 0x3f;
byte c = (byte)( a & b);

Insofern bleibe ich dabei, daß das Verwenden von Casts nichts mit "unsauberer" Programmierung zu tun hat.

 

[Beni]

Na gut, eine allgemeingültige Form von "sauber Programmiert" gibt es nicht. Und beim byte-int-Geschmeus kann man manchmal wirklich nicht anders.
Wenn es um Objekte geht, bleib ich dabei. Man kommt ohne herumgecaste (und Java 1.5) sehr weit. Da jeder Cast eine potentielle Fehlerquelle ist (einmal ein falsches Objekt in der Collection, und *buum*), verzichte ich lieber, und schreib mir ein Interface mehr :wink: