returnvalue einer geerbten Methode ändern?

[flo123]

Hallo,

gibt es eine Möglichkeit, den Rückgabewert einer geerbten Methode zu ändern? Beispiel: Klasse A hat die Methode getDate(), die ein Calendar liefert. Klasse B erbt von Klasse A und will eine Methode getDate() implementieren, die einen String liefert.
Irgendwie muss das doch gehen ... Ich brauche das im Zusammenhang mit dem Decoratorpattern. Die Dekoration soll einen String liefern, kein Calendar.


Danke!

 

[SebiB90]

den typ des return values kannste nicht ändern

 

[SamHotte]

Nein, bei Vererbung geht das nicht. Mit Komposition ließe sich das machen.

 

[Leroy42]

Das kann nicht gehen: Fehlermeldung

... in B cannot override ... in A; attempting to use incompatible return type

Beschreib doch mal, was du vorhast, das Decorater-Pattern kenne ich nicht, aber
es kann so etwas nicht voraussetzen.

 

[Guest]

Ich habe eine Klasse A, die ich dekorieren möchte. Das bedeutet, dass es eine Klasse B gibt, die von A erbt und gleichzeitig Klasse A wrappt, dh sie als Attribut enthält. Methodenaufrufe an A werden so von B abgefangen und können manipuliert werden. Dummerweise muss ich die so manipulieren, dass hinten ein String rauspurzelt, und kein Calendar.


Klasse A

public Calendar getDate() {
return Calendar;
}

Klasse B

public abstract class B extends A {
protected A nameA;
public abstract [b]String[/b] getDate();

Klasse C

public class C extends B {
public String getDate() {
return "";
}

C wird benutzt. Das Decoratorpattern erlaubt es, Objekte dynamisch zu ändern. Ich kann in C den Aufruf abfangen und was anderes zurückgeben. Für den Aufrufer sehen die Objekte immer noch wie A aus. Wahrscheinlich kann ich deshalb auch nicht den Rückgabetyp ändern ...

Aber wie könnte man das lösen? ???:L

 

[SebiB90]

ich versteh den sinn dahinter nicht
wieso soll eine klasse von einer erben und sie gleichzeitig als attribut haben?

 

[Guest]

ich versteh den sinn dahinter nicht
wieso soll eine klasse von einer erben und sie gleichzeitig als attribut haben?

Decoratorpattern

Das erklärt das Ganze ausführlicher

 

[SebiB90]

also irgendwie sieht mir aus als ob du das mit "super" lösen kannst

also das beispiel:

public String getDescription() {
        return decoratedWindow.getDescription() + ", including horizontal scrollbars";
    }

kannste in java so lösen:

public String getDescription() {
        return super.getDescription() + ", including horizontal scrollbars";
    }

super greift auf die methoden der oberklassen zu, so brauchste kein attribut der oberklasse

 

[SlaterB]

wie der Link beschreibt gehts bei Decorator ja darum,
gleichzeitig eine erweiterte Funktionalität zur Verfügung zu stellen,
aber auch die eigentliche Komponente zur Laufzeit austauschen zu können,
bzw. mehrere Objekte mit verschiedenen 'eigentlichen Komponenten' zu erzeugen

deshalb die 'Oberklasse' als Attribut und nicht als feste Oberklasse,

-------

wie dort aber auch zweifelsfrei steht:
"The interface of the original object needs to be maintained by the decorator."

daher kann man
Calendar getDate()
unmöglich in
String getDate()
umwandeln, und es hätte auch nix mit dem Decorator-Pattern zu tun,
String getDate() ist eine völlig andere, dem Interface der Oberklasse unbekannte Operation,

falls du unabhängig vom Interface der Oberklasse einfach so diese neue Operation hinzufügen wolltest:
tja das ist dann Pech wenn es eine gleichnamige Operation schon gibt,
alles ist eben nicht möglich,

wie sollte die Java-VM zur Laufzeit wissen, ob bei einem Aufruf
Object x = b.getDate(); die String- oder die Date-Operation gemeint ist?,

sowas ist unmöglich, unabhängig von irgendwelchen Pattern

 

[SnooP]

Kannst du nicht nen eigenen Typ erstellen und zurückgeben lassen? Dieser Typ enthält dann sowohl den Calender als auch den String den du zurückgeben willst... dann kannst du dich je nach Laune entscheiden.

 

[byte]

Warum musst Du überhaupt nen String zurückgeben? Ich sehe eigentlich keinen Sinn darin. Strings sind dafür da, um etwas auszugeben. Dazu erbt jede Klasse die toString() von Object und überschreibt sie bei Bedarf sinnvoll. Arbeite also mit den Date-Objekten und hole Dir bei Bedarf die String-Repräsentation mit date.toString().

 

[Guest]

Ja, lässt sich wohl nicht anders lösen als die toString() Methode zu überladen. Oder ich füge eine zusätzliche Methode ein, aber die erkennt man dann ja nur, wenn man auf das dekorierte Objekt castet.

Danke für die Antworten!

 

[Guest]

wie der Link beschreibt gehts bei Decorator ja darum,
gleichzeitig eine erweiterte Funktionalität zur Verfügung zu stellen,
aber auch die eigentliche Komponente zur Laufzeit austauschen zu können,
bzw. mehrere Objekte mit verschiedenen 'eigentlichen Komponenten' zu erzeugen

deshalb die 'Oberklasse' als Attribut und nicht als feste Oberklasse,

Die Oberklasse (die Komponente) ist Oberklasse UND Attribut.

 

[flo123]

Ich schon wieder
Ein Kollege hatte gestern eine super Idee, wie man toString() überladen könnte bzw. das dynamischer macht. Irgendwas mit "now". Dummerweise ist der heute nicht da Wie könnte ich also das toString von Calendar ändern (mit now?)? Was wäre da das eleganteste Standardvorgehen? Ich habe das bisher nur gemacht, wenn ich komplett eigene Klassen erzeugt habe.

 

[SlaterB]

wie der Link beschreibt gehts bei Decorator ja darum,
gleichzeitig eine erweiterte Funktionalität zur Verfügung zu stellen,
aber auch die eigentliche Komponente zur Laufzeit austauschen zu können,
bzw. mehrere Objekte mit verschiedenen 'eigentlichen Komponenten' zu erzeugen

deshalb die 'Oberklasse' als Attribut und nicht als feste Oberklasse,

Die Oberklasse (die Komponente) ist Oberklasse UND Attribut.

ich denke aber mal Oberklasse nur als Interface oder?
alle Aufrufe werden wohl an das Attribut weitergeleitet und nie an die Oberklasse?
habs noch nie (bewußt) benutzt

 

[Guest]

wie der Link beschreibt gehts bei Decorator ja darum,
gleichzeitig eine erweiterte Funktionalität zur Verfügung zu stellen,
aber auch die eigentliche Komponente zur Laufzeit austauschen zu können,
bzw. mehrere Objekte mit verschiedenen 'eigentlichen Komponenten' zu erzeugen

deshalb die 'Oberklasse' als Attribut und nicht als feste Oberklasse,

Die Oberklasse (die Komponente) ist Oberklasse UND Attribut.

ich denke aber mal Oberklasse nur als Interface oder?
alle Aufrufe werden wohl an das Attribut weitergeleitet und nie an die Oberklasse?
habs noch nie (bewußt) benutzt

Nein, ganz 'normal' per extend. So ist es zumindest überall modelliert, ich mach das auch gerade zum Ersten Mal
Der Wrapper bietet damit die gleichen Methoden wie das original Objekt an, und kann die entsprechend verwursten, wenn er das möchte. Um an die richtigen Daten bzw. das richtige Objekt zu kommen, besitzt er die Komponente als Attribut. Auf diese Art kann die Komponente bereits dekoriert sein, das Ganze lässt sich beliebig verschachteln.


Aber zurück zu der toString() Frage weiter oben. Wie geht datt?

 

[SlaterB]

bist du denn auch der flo123?

zunächst mal einfach die Data-Klasse ableiten, ein Objekt vom Typ MyDate statt Date zurückgeben

class MyDate extends Date {
..
public String toString() {
String alt = super.toString();
return ..
}
}

toString könnte dann immer den neue Ausgabe zurückgegen oder auch abhängig von einem aktuellen Zustand verschiedene Texte,

wüßte aber nicht warum man in dieser Situation irgendwas 'dynamisch' machen sollte

 

[flo123]

Ja, bin immer der flo123

Also Du meinst ich sollte eine neue Klasse erstellen, die ich im Wrapper, also dekorierten Objekt, als Rückgabetyp benutze? Und das geht, weil sie ja vom originalen Rückgabetyp erbt, hat aber ein richtiges toString(). Hmm, ok, ist ja eigentlich recht einfach, wenn ich as richtig verstanden habe

Ist einfach zu heiß hier, 33° und es ist erst 11.00 Uhr. Urghs...

 

[byte]

ich denke aber mal Oberklasse nur als Interface oder?
alle Aufrufe werden wohl an das Attribut weitergeleitet und nie an die Oberklasse?

Ist völlig wurscht, obs ne abstrakte Oberklasse oder ein Interface ist. Es geht einfach darum, dass der Dekorierer die gleiche Schnittstelle hat wie die zu dekorierenden Objekte, so dass man beide gleich behandeln kann und sich am Ende nicht mehr drum kümmern muss, ob das nun eine "normale" Komponente ist oder eine Komponente, die ein oder mehrmals dekoriert wurde.

 

[SlaterB]

nach außen wirkt es gleich,
ich wollte ja nur sagen dass hier was anderes als eine normale Vererbung vorliegt,
indem nämlich die Hauptaufgabe der Vererbung (Superklasse nutzen) völlig ignoriert wird,

gäbe es zu der Oberklasse ein Interface, dann müsste überhaupt nicht erst geerbt werden,
es würde reichen, das Interface zu implementieren,

die Oberklasse wird ALS OBERKLASSE überhaupt nicht angesprochen, sondern nur das enthaltene Attribut

 

[byte]

Wenn es keine Implementierung gibt, die man in die abstrakte Oberklasse auslagern könnte, dann kann man natürlich auch ein Interface verwenden, ganz klar. Das gilt aber für nahezu alle Pattern und ist auch nur eine Eigenheit von Java. Denn Interfaces gibt es (afaik) in keiner anderen Programmiersprache. Das spielt für das Verständnis der Pattern keine Rolle. Es geht ja einfach darum, eine gemeinsame Schnittstelle anzubieten.

die Oberklasse wird ALS OBERKLASSE überhaupt nicht angesprochen, sondern nur das enthaltene Attribut

Nein. Die Oberklasse definiert eine Schnittstelle. Und die wird auch verwendet.

 

[SlaterB]

dir kann mans wohl nicht genau genug machen

akzeptierst du 'Operationen der Oberklasse werden nie durch super()-Aufrufe oder vergessene Überlagerung ausgeführt'?

es gibt auch keine ((halbabstrakten) Teiloperationen die zur Anwendung kommen könnten,
alles hängt von der Implemenierung des Objektes ab, dass als Attribut im Dekorator enthalten ist

 

[byte]

Ich will mal nicht so sein und akzeptiere das so.

Aber nur ausnahmsweise, also gewöhn Dich nicht dran. :bae: