Override in Interfaces

[Kirias]

Guten Abend allerseits!

Habe folgende Situation:

Interfacehierarchie

public abstract interface Value{

	abstract double getValue();
}

vererbt an

public interface Value1D extends Value {

	double getValue(double state);
}

wird implementiert durch:

public class Swaption extends Option implements Value1D {
	//is an option on an interest rate swap
	do lalala...
        
        public double getValue(double underlyingValue){
		do lalala2
		return value;
	}
}

Jetzt meckert er, dass ich zwar die direkte Methode aus dem Interface Value1D implementiert habe, aber nicht die Methode aus dem SuperInterface Value. Müsste die nicht üerlagert worden sein? Ich versteh es nicht...

Liebe Grüße
Kirias[/code]

 

[Beni]

Wichtig ist nicht nur der Name einer Methode, auch die Argumente sind Teil der Signatur.

Vergleich mal:

double getValue() // Interface Value
double getValue( double ) // Interface ValueID

Das sind zwei verschiedene Methoden. Die eine benötigt was zum rumrechnen, die andere nicht.

 

[bygones]

die beiden methoden haben eine untersch. signatur....

double getValue()
getValue(double state)

....

 

[Kirias]

wie kriege ich dann da ein sauberes override hin? im SuperInterface

abstract double getValue(Object object);

verwenden?

müsste ich dann casten? wenn ja in welcher reihenfolge?


muss schon sagen ... java ist ganz schön komplex...

 

[Kirias]

ach ja, ganz vergessen: ich dachte, dass ich das Problem der verschiedenen Parameter mit "abstract" ausgemerzt hätte?

 

[Illuvatar]

ach ja, ganz vergessen: ich dachte, dass ich das Problem der verschiedenen Parameter mit "abstract" ausgemerzt hätte?

Nein, das hat nichts miteinander zu tun.
abstract hat in interfaces keine Bedeutung, das das implizit immer dasteht.

Du müsstest eben in der implementierenden Klasse beide Methoden implementieren...

 

[Kirias]

... und dann die "falsche" zur Sicherheit private deklarieren und unbenutzt lassen ... ok

 

[bygones]

... und dann die "falsche" zur Sicherheit private deklarieren und unbenutzt lassen ... ok

das wird nicht gehen... man kann die Sichtbarkeit einer vererbten methode nicht verringern.

entweder gleiche signatur - dann stellt sich aber die frage nach dem sinn der beiden interfaces - oder eine leere Implementation in der Klasse oder eine NoSuchMethodException schmeißen z.b

 

[Kirias]

ich habe jetzt die Hierarchie weggelassen, da ich etwas unter Zeitdruck stehe und das nicht nach einer schnellen Lösung aussieht (das ist erste meine erste Woche in Java und ich kann mich da nicht mehr so weit reinfuchsen). Trotz allem vielen Dank für die Lösungsvorschläge!!!

Aber um bei der Diskussion zu bleiben: Es muss doch möglich sein, eine der Klassenhierarchie entsprechende Interfacehierarchie aufbauen zu können ohne rumtricksen zu müssen. Schließlich kann ich auf Klassenebene auch abstrakte Methoden aufbauen. wieso nicht auch abstrakte Interfacelayer? Die Lösung der "leeren" Methoden halte ich nicht für sinnvoll, da dann der Sinn der Interfaces völlig übergangen wird. Das muss auch anders möglich sein.

 

[bygones]

aber um bei der Diskussion zu bleiben: Es muss doch möglich sein, eine der Klassenhierarchie entsprechende Interfacehierarchie aufbauen zu können ohne rumtricksen zu müssen. Schließlich kann ich auf Klassenebene auch abstrakte Methoden aufbauen. wieso nicht auch abstrakte Interfacelayer? Die Lösung der "leeren" Methoden halte ich nicht für sinnvoll, da dann der Sinn der Interfaces völlig übergangen wird. Das muss auch anders möglich sein.

klar kann man das ohne rumzutricksen - man muss nur eine klare und logische Struktur in der Verberungshierarchie bzw. Implementationshierarchie haben....

bei dir ist die Sache einfach: du die Klasse implementiert 2 Interfaces, in denen sind zwei Methoden vorgegeben, ergo muss deine Klasse die beiden Methoden implementieren.....

 

[SlaterB]

abstrakte Klasse bedeutet einfach nur dass ein Teil der Klasse ein Interface ist,
also Signaturen von Operationen ohne deren Implementation enthält

Interface sind demnach IMMER komplett abstrakt per Definition,
es macht keinen Sinn da irgendwas noch abstrakter zu machen

und deine Frage
"Es muss doch möglich sein [..] wieso nicht auch abstrakte Interfacelayer?"
bietet ohne genauere Begründung keinen Angriffspunkt um dir das auszureden,
wieso sollte das deiner Meinung nach so sein?


abstrakt hat in Klassen (wie bei gesamten Interfacen) immer nur mit Signatur <-> Implementierung zu tun,
genauso bezieht sich Überschreiben immer nur auf eine feste Signatur,

wenn du weitere Parameter an die Operation hinzufügst ist das eine völlig andere,
dann ist Java total egal dass der Operationsname gleich ist!

-------
was bisher nur halb erwähnt wurde und dir vielleicht noch unklar erscheint:
die einzige Möglichkeit in deinem Fall Operationen zu überschreiben:

public interface Value{

    double getValue();
}

public interface Value1D extends Value {

   double getValue();
}

dies macht aber keinen Sinn denn die Operation "double getValue();" ist im Interface Value1D sowieso schon enthalten durch die Vererbung,
es ändert sich absolut nix

 

[Kirias]

Ok, habe ich verstanden.
Interfaces sind per se abstrakt, denn sonst könnten sie ihre Funktion nicht ausfüllen. Deswegen macht es auch keinen Sinne ein "abstraktes" interface aufzubauen.
Ein override ist nur bei gleichen Parametern möglich.

Vielen Dank!