Überlagerung per Interface verpflichtend machen

[Toddy]

Ich möchte, daß jede Klasse die das Interface implementiert die Methode nicht nur implementiert, sondern sie überlagern muß. Da es sich bei der Methode um toString() handelt, die sowieso implementiert ist, gestaltet sich das nämlich garnicht so einfach.

interface Beispiel1 {
	public String toString();
}

interface Beispiel2 {
	@Override
	public String toString();
}

Beispiel1 bringt mir nicht viel. Die Klasse Object implementiert das schon, und es gibt beim compilieren keinen Grund es mir anzukreiden, wenn ichs nicht selbst implementiere. Also dachte ich mir, ich verwende das @Override Pragma im Interface, aber das funktioniert auch nicht. Gibt es eine andere Möglichkeit für mein Vorhaben?

 

[musiKk]

Mit Interfaces nicht, aber Du kannst die Methode in einer abstrakten Klasse als abstrakt vorgeben. Dann muss sie implementiert werden.

 

[Toddy]

Hm, abstrakte Klasse kommt bloß leider nicht in Frage, da ich das in Ableitungen verschiedener Basisklassen implementiere. Das Problem läßt sich zum Glück verhältnismäßig einfach umgehen, in dem ich nun einfach getName() einführe. Ist zwar nicht ganz so schön, aber so kann ich wenigstens sicher gehen, daß es korrekt implementiert wird.

Falls es doch einen Weg geben sollte, das unter Nutzung eines Interfaces zu umgehen, wäre ich dennoch an der Lösung interessiert.

 

[musiKk]

Ich finde Deine Lösung eigentlich schöner. toString() ist einfach nur eine textuelle Darstellung einer Instanz eines Objekts ohne besondere Anforderungen. Sie soll von Menschen lesbar sein und es wird "empfohlen", die Methode zu überschreiben. Mitten in der Klassenhierarchie aber auf einmal diese Anforderung zu ändern, sorgt nicht gerade für Übersichtlichkeit. Streng genommen verstößt das auch gegen das Substitutionsprinzip. Wäre hier im konkreten Fall wahrscheinlich nicht so schlimm, aber alles andere als schön.

 

[sliwalker]

Auch nicht schöner, aber Du könntest die Signatur im Interface ändern, dass unterscheiden sich auch die Object.toString() und Deine neue toString(Object o).

Ist nur ziemlich sinnfrei einfach immer null mit zu übergeben.
Funktioniert aber...

 

[Andreas29]

Hi,

also, ich denke auch, dass die Idee der getName() Methode die besser ist. Denn man sollte es vermeiden, seine Business logik vom vorhandensein dieser Methode abhängig zu machen. Das ist kein guter Stil und sehr riskant.

@musiKk:
Ob nun Interface oder abstrakte Klasse, da toString() auf Obeject schon als konkrete Methode implementiert ist, brauche ich sie auf meiner Klasse nicht erneut hinschreiben, egal ob sie auf irgendeinem Interface oder einer abstrakten Klasse vorgegeben ist. Denn wenn eine Methode auf einer parent-Klasse implementiert ist, ist sie implementiert. Fertig.

Grüße,
Andreas

 

[musiKk]

@musiKk:
Ob nun Interface oder abstrakte Klasse, da toString() auf Obeject schon als konkrete Methode implementiert ist, brauche ich sie auf meiner Klasse nicht erneut hinschreiben, egal ob sie auf irgendeinem Interface oder einer abstrakten Klasse vorgegeben ist. Denn wenn eine Methode auf einer parent-Klasse implementiert ist, ist sie implementiert. Fertig.

Nein. Glaub mir, ich habe das ausprobiert, bevor ich diese Aussage getätigt habe.

 

[sliwalker]

ACK musiKk.

Ich konnte es auch nicht glauben und habe es probiert.
Tatsächlich meckert eclipse. Warum, das ist mir noch nicht ganz klar.
Kann das jemand erklären?

 

[musiKk]

Nun... weil die Methode als abstrakt markiert ist. Mehr ist doch nicht dahinter?

Every subclass of A that is not abstract must provide an implementation for m, or a compile-time error occurs

Das Beispiel dort verwendet sogar toString().

 

[sliwalker]

Aha,

nun ja, man könnte ja sagen, dass es die Methode schon gibt, da immer von Object abgeleitet.
Und beim interface ist es ja dasselbe. Das Interface macht keine Probleme, da erkennt der compiler, dass es die Methode gibt.

Bei abstract, wenn ich recht überlege, muss die erste non-abstract Klasse eine Implementierung bieten.
Ich hätte nun gesagt, die ist ja schon da. Aber irgendwas muss anders sein. Kann mir nur vorstellen,d ass der Compiler bei abstract explizit darauf achtet, dass in der direkten ersten non-abstract Klasse eine explizite Implementierung dieser Methode enthalten sein muss. "Abstract sucht nicht in der Vererbungshirachie".

Was anderes fällt mir nicht ein.