Polymorphie Frage zur Methodenüberschreibung

[JavaSchmecktLecker]

Hi, habe eine Aufgabe vor mir, die ich meiner Meinung nach richtig gelöst habe, zumindest hoffe ich, das ich sie richtig verstanden habe. Wäre super wenn jemand mal darüber schaut, vielleicht hat jemand einen anderen Ideengang / Meinung.

Sie haben folgende Basisklasse Insekt:

Leiten Sie aus dieser Basisklasse eine Klasse Biene ab. Die Klasse Biene soll zusätz-
lich eine Instanzvariable geschwindigkeit enthalten, die über einen Konstruktor
mit einem beliebigen Wert initialisiert werden kann.
    
Ändern Sie auch die Methode ausgabe() der Klasse Biene so, dass zusätzlich die
Geschwindigkeit ausgegeben wird.
    
//genau hier habe ich etwas Zweifel
Stellen Sie in Ihrem Programm sicher, dass die Methode ausgabe() in der Klasse
Biene die Methode ausgabe() in der Klasse Insekt in jedem Fall überschreibt.
    
Testen Sie Ihre neue Klasse, indem Sie eine main()-Methode schreiben und in dieser
je ein Objekt der Basisklasse und der abgeleiteten Klasse erzeugen und jeweils beide
Methoden mindestens einmal aufrufen.

    
class Insekt {
int laenge;
int gewicht;
//der Konstruktor
Insekt(int laenge, int gewicht) {
this.laenge = laenge;
this.gewicht = gewicht;
}
//die Methode zum Essen
void essen() {
laenge = laenge + 1;
gewicht = gewicht + 1;
}
//die Methode zur Ausgabe
void ausgabe() {
System.out.println("Das Insekt ist " + laenge + " cm lang
und wiegt " + gewicht + " Gramm.");
}
}

Und das hier habe ich bisher programmiert:

package testPaket;

class Insekt {
    int laenge;
    int gewicht;
//der Konstruktor

    Insekt(int laenge, int gewicht) {
        this.laenge = laenge;
        this.gewicht = gewicht;
    }

//die Methode zum Essen
    void essen() {
        laenge = laenge + 1;
        gewicht = gewicht + 1;
    }
    

//die Methode zur Ausgabe
    void ausgabe() {
        System.out.println("Die Ausgabe erfolgt aus " + this.getClass());
        System.out.println("Das Insekt ist " + laenge + " cm lang und wiegt " + gewicht + " Gramm.");
    }

    @Override
    public String toString() {
        String ausgabe;
        ausgabe = "" + this.getClass();
        ausgabe = ausgabe + laenge;
        ausgabe = ausgabe + gewicht;
        return ausgabe;
    }
}

//die Klasse Biene kreieren
class Biene extends Insekt {
//geschwindigkeit hinzufuegen
    int geschwindigkeit;

    // inistialisierung des Konstruktors Biene
    Biene(int laenge, int gewicht, int geschwindigkeit) {
        super(laenge, gewicht);
        this.geschwindigkeit = geschwindigkeit;
    }

    
    @Override
    public String toString() {
        String ausgabe;
        ausgabe = super.toString();
        ausgabe = ausgabe + " & fliegt " + geschwindigkeit + " Stundenkilometer";
        return ausgabe;
    }

    @Override
    void ausgabe() {
    System.out.println ("Die Ausgabe erfolgt aus " + this.getClass());
    System.out.println ("Die Biene ist " + laenge + " Millimeter gross, " + gewicht + "" + " Milligramm schwer & fliegt " + geschwindigkeit + " Stundenkilometer");
     }

}

public class testKlasse {

    public static void main(String[] args) {
        Insekt insekt1 = new Insekt(30, 20);
        Biene biene1 = new Biene(15, 1, 32);

        // hier sind die Daten der Tiere
        biene1.ausgabe();
        insekt1.ausgabe();

        // hier essen die Tiere
        biene1.essen();
        insekt1.essen();

        // nach dem essen, laenger und schwerer
        biene1.ausgabe();
        insekt1.ausgabe();

    }
}

Und diese Ausgabe wirft mein Compiler heraus:

Die Ausgabe erfolgt aus class testPaket.Biene
Die Biene ist 15 Millimeter gross, 1 Milligramm schwer & fliegt 32 Stundenkilometer
Die Ausgabe erfolgt aus class testPaket.Insekt
Das Insekt ist 30 cm lang und wiegt 20 Gramm.
Die Ausgabe erfolgt aus class testPaket.Biene
Die Biene ist 16 Millimeter gross, 2 Milligramm schwer & fliegt 32 Stundenkilometer
Die Ausgabe erfolgt aus class testPaket.Insekt
Das Insekt ist 31 cm lang und wiegt 21 Gramm.

Vielen Dank und beste Grüsse 🙏

 

[Neumi5694]

Schaut so weit gut aus, die Aufgabe ist erfüllt.

 

[temi]

//genau hier habe ich etwas Zweifel Stellen Sie in Ihrem Programm sicher, dass die Methode ausgabe() in der Klasse Biene die Methode ausgabe() in der Klasse Insekt in jedem Fall überschreibt.

Ich denke, dass damit die Verwendung der Annotation @Override gemeint ist. Diese würde zu einer Fehlermeldung führen, wenn die Methode nicht überschrieben würde, weil z. B. die Signatur nicht korrekt ist.

 

[JavaSchmecktLecker]

Merci.

 

[vup]

damit die Verwendung der Annotation @Override gemeint ist. Diese würde zu einer Fehlermeldung führen, wenn die Methode nicht überschrieben würde

Das stimmt so nicht. Zwischen beiden Aussagen besteht keine Kausalität. die Override-Annotation ist optional und dient nur der besseren Übersichtlichkeit.

 

[KonradN]

Ich sehe es genau so, wie @temi.

Durch die Annotation @Override stellt der Compiler sicher, dass die Methode ausgabe() von Biene eine Methode ausgabe() der übergeordneten Klasse (Insekt) überschreibt.

Es ist eben nicht nur eine Sache der Übersichtlichkeit sondern auch ein Überprüfung die andernfalls einen Fehler bringt.

Dazu kann man sich einfach die JLS 9.6.4.4 ansehen:

Chapter 9. Interfaces

Programmers occasionally overload a method declaration when they mean to override it, leading to subtle problems. The annotation interface Override supports early detection of such problems.

Im Anschluss folgt ein Beispiel das aufzeigt, was @temi mit

weil z. B. die Signatur nicht korrekt ist.

meinte.

Über das Wording mag man sich streiten - gerade bei der Nutzung deutscher Begriffe, aber ich würde vermuten, dass dann in Unterricht/Vorlesung dieser Aspekt behandelt wurde und es sich eben auch genau auf diesen Aspekt bezieht. Ich wüsste ansonsten gerade nicht, auf was sich die gewählte Formulierung sonst beziehen sollte.

 

[vup]

Durch die Annotation @Override stellt der Compiler sicher, dass die Methode ausgabe() von Biene eine Methode ausgabe() der übergeordneten Klasse (Insekt) überschreibt

Das ist Blödsinn. So wie es ja auch schon in der von dir verlinkten JLS erklärt wird, beeinflusst die Override-Annotation die Compiler-checks in keinster Weise. Der Compiler wirft mit oder ohne Annotation eine Fehlermeldung, wenn abstrakte Methoden, die überschrieben werden müssen, nicht überschrieben wurden. => optional

 

[KonradN]

Der Compiler wirft mit oder ohne Annotation eine Fehlermeldung, wenn abstrakte Methoden, die überschrieben werden müssen, nicht überschrieben wurden. => optional

Ich fürchte, du wirfst da ein paar Dinge durcheinander.

a) Bei abstrakten Methoden wirft der Compiler aber nur einen Fehler, wenn die Klasse nicht auch abstrakt ist. Das ist kein Thema bezüglich Override sondern schlicht die Regel bei abstrakten Klassen. Eine Klasse, die nicht abstrakt ist, darf keine abstrakten Methoden haben.

Chapter 8. Classes

A normal class may have abstract methods, that is, methods that are declared but not yet implemented (§8.4.3.1), only if it is an abstract class. It is a compile-time error if a normal class that is not abstract has an abstract method.

b) Das @Override ist unabhängig vom Schlüsselwort abstract. So wie Deine Aussage schon etwas impliziert: Ist die Methode, die überschrieben wird, nicht abstrakt ist, dann wird auch kein Fehler geworfen. Denn dann ist es einfach eine weitere, neue Methode mit gleichem Namen aber anderer Signatur. (Overloading - JLS 8.4.9 https://docs.oracle.com/javase/specs/jls/se20/html/jls-8.html#jls-8.4.9)

Und wenn Du in den Code des OP schaust: Dort geht es nicht um das Überschreiben einer abstrakten Methode (ausgeben() ist in Insekt nicht abstract). Daher würde es dort keine Fehlermeldung geben und auch kein Check des Compilers, dass ausgeben von Insekt überschrieben wird.

Und auch wenn Du dem Link von mir folgst, findest Du genau so ein Beispiel:
Die equals Methode von Object soll da überschrieben werden in einer Klasse Foo und bei public boolean equals(Foo that) { ... } wird equals nicht überschrieben.

 

[temi]

Das ist Blödsinn. So wie es ja auch schon in der von dir verlinkten JLS erklärt wird, beeinflusst die Override-Annotation die Compiler-checks in keinster Weise.

Probiere es doch einfach mal aus. Beachte dabei, dass es sich nicht um eine abstrakte Methode handelt.

Falls du zu faul dazu bist, so sieht die entsprechende Meldung aus: error: method does not override or implement a method from a supertype

Lass mich raten: Tobias...

 

[Neumi5694]

Hatte mal irgendwo gelesen, dass man diese Prüfung auch ausschalten kann, insofern wäre "optional" schon richtig. Aber in der Standardeinstellung wird sie durchgeführt.

 

[vup]

dass es sich nicht um eine abstrakte Methode handelt

Das wäre mir sicher aufgefallen, wenn der Code nicht so grauenhaft/ gar nicht formatiert sein würde.

 

[temi]

Das wäre mir sicher aufgefallen, wenn der Code nicht so grauenhaft/ gar nicht formatiert sein würde.

Hauptsache jemand anderes war schuld...

 

[KonradN]

Hatte mal irgendwo gelesen, dass man diese Prüfung auch ausschalten kann, insofern wäre "optional" schon richtig. Aber in der Standardeinstellung wird sie durchgeführt.

Das würde keinen Sinn machen. Ein Schalter um Dinge in der JLS abzustellen?

Ich habe den Link zu diesem Punkt doch bereits gebracht und auch wenn ich das Zitat kurz gehalten habe, findet sich da:

If a method declaration in class or interface Q is annotated with @Override, then one of the following three conditions must be true, or a compile-time error occurs:

• the method overrides from Q a method declared in a supertype of Q (§8.4.8.1, §9.4.1.1)
• the method is override-equivalent to a public method of Object (§4.3.2, §8.4.2)
• Q is a record class (§8.10), and the method is an accessor method for a record component of Q (§8.10.3)

"or a compile-time error occurs" ist doch eindeutig.

Ich bezweifle, dass der Java Compiler Schalter hat, die Elemente der JLS aushebeln.

Aber ich lasse mich gerne eines besseren belehren....

 

[KonradN]

Das wäre mir sicher aufgefallen, wenn der Code nicht so grauenhaft/ gar nicht formatiert sein würde.

a) Die JLS ist bei den diversen Punkten deutlich. Man muss also nicht den Code des TE lesen um die einzelnen compile-time Fehler zu kennen und zu verstehen. (Die relevanten JLS Stellen habe ich aufgezeigt!)

b) Ich finde es wenig zielführend, wenn man die Fragestellung nicht / nicht ausreichend liest und dann Aussagen bezüglich der Aufgabe einfach abstempelt als

Das ist Blödsinn.

Wobei sich das ja weiter durchzieht - die verlinkte JLS hast Du dir ganz offensichtlich auch nicht im Detail angesehen, sonst wäre der darauf folgende Hinweis nicht notwendig gewesen.

Das aber nur als kleiner, dezenter Hinweis, weil es mir halt so auffällt. Natürlich steht es Dir weiter frei, so zu agieren. Ich habe kein Problem damit, so einfache Dinge richtig zu stellen. Und JLS zu lesen scheint ja auch für andere Personen nicht zumutbar zu sein.

 

[Neumi5694]

Das würde keinen Sinn machen. Ein Schalter um Dinge in der JLS abzustellen?

Naja, die @Override Annotation hat keinen praktischen Sinn, dient nur zur Fehlerkontrolle und Lesbarkeit. In sehr altem Code findet man die so gut wie gar nicht und auch mit neuen Java Versionen läuft der Code ohne diese.
Es spräche nichts dagegen, die Kontrolle überhaupt wegzulassen, für die Funktion des Programms würde das keinen Unterschied machen.
Ob's nun wirklich geht oder nicht, das ist mir jetzt nicht wichtig genug, um Zeit darin zu investieren.

 

[mihe7]

Naja, die @Override Annotation hat keinen praktischen Sinn, dient nur zur Fehlerkontrolle und Lesbarkeit.

Fehlerkontrolle und Lesbarkeit sind aber doch sehr praktische Sinne

 

[Neumi5694]

Fehlerkontrolle und Lesbarkeit sind aber doch sehr praktische Sinne

Ich meinte natürlich bezüglich der Code-Generierung des Kompilers, aber das Statement ist absolut richtig

 

[KonradN]

Naja, die @Override Annotation hat keinen praktischen Sinn, dient nur zur Fehlerkontrolle und Lesbarkeit. In sehr altem Code findet man die so gut wie gar nicht und auch mit neuen Java Versionen läuft der Code ohne diese.
Es spräche nichts dagegen, die Kontrolle überhaupt wegzulassen, für die Funktion des Programms würde das keinen Unterschied machen.
Ob's nun wirklich geht oder nicht, das ist mir jetzt nicht wichtig genug, um Zeit darin zu investieren.

Dazu fällt mir ein:

a) Die ganze Java Sprache ist doch Obsolet. Die nutzt man am Ende doch gar nicht! Am Ende werden nur 1er und 0er von einer CPU ausgewertet.
Also könnte man diese auch direkt schreiben. Das dient ja nur zur Fehlerkontrolle und Lesbarkeit!

b) Ja, so der Code korrekt ist (!!) macht es keinen Unterschied, ob da ein @Override steht oder nicht. Das ist richtig. Der Unterschied ist erst, wenn der Code nicht korrekt ist. Und ja - wenn es einen nicht interessiert "Ob's nun wirklich geht oder nicht", dann braucht man das nicht. Dann braucht man auch kein Clean Code oder so. Nur mir fehlt da jedes Verständnis: Was für eine Vorstellung ist das? Damit ist jede QA hinfällig. Da würde sich mir direkt die Frage stellen, in wie weit das sogar in D ein direkter Kündigungsgrund ist. Aber ja: Das ist genau das, was ich sehr oft erlebe - die Leute sind auf sich selbst bezogen und haben absolut kein Interesse an der Außenwelt. Egal ob etwas geht oder nicht, egal, ob Menschenleben gefährdet werden, .... alles egal ... Ich bin da immer wieder sehr erstaunt. Das ist halt nicht meine Sichtweise.

 

[Neumi5694]

Was du in meine Posts reininterpretierst, bleibt ganz dir überlassen. Dass du hier gerade deine eigene Fantasie kritisierst, muss dir aber schon klar sein. Wenn du an dem gesagten was auszusetzen hast, dann ist das natürlich vollkommen ok, aber deine geistigen Ausflüge gehen mich wenig an. In dem Fall solltest du auf Zitate verzichten.

 

[KonradN]

Vielleicht solltest Du dann einfach einmal bei Deinen Aussagen etwas exakter sein oder diese verständlicher formulieren?

Sorry, aber was soll man in eine Aussage hinein interpretieren wie:

Ob's nun wirklich geht oder nicht, das ist mir jetzt nicht wichtig genug, um Zeit darin zu investieren.

Sorry, aber das ist doch relativ eindeutig. Mag sein, dass Du damit nur meinst, dass Du in diese Thematik mit dem @Override keine Zeit investieren willst - was aber doch auch nichts ändert. Das besagt ja auch nur: Ich mische hier mit aber Zeit in die Thematik investiere ich nicht. Schon #10 war da sehr interessant - aber dazu ist ja auch nichts mehr gekommen ...

Sorry, aber ich habe gerade sehr wenig Verständnis für Dich. Ist aber auch egal. Ich werde mich nicht mehr an Leuten wie Tobias und Dir abarbeiten. Ich denke, dass die fachliche Seite gute abgearbeitet wurde so dass es hier nichts weiter zu sagen gibt.

 

[mihe7]

Ich meinte natürlich bezüglich der Code-Generierung des Kompilers,

Gerade diesbezüglich macht es doch den Unterschied: ohne die Annotation kann anderer Code geschrieben und generiert werden als mit.

Das ist genau wie bei "final". Damit kann ich auch festlegen, dass eine Methode nicht überschrieben werden darf. Probiere ich es trotzdem, gibt es einen Fehler. Natürlich ist die Intention dahinter eine andere, aber vom Prinzip her ist die Annotation auch nichts anderes, nur eben in die andere Richtung ("diese Methode muss eine andere überschreiben").

Man hätte die Annotation also durchaus wie "final" als verpflichtendes Schlüsselwort in die Sprache einführen können: wer eine Methode überschreiben will, muss override dazuschreiben (fehlt das -> compile time error).

public override String toString() { ... }

Aber erstens hätten dann Milliarden an Codezeilen geändert werden müssen und zweitens ist die Zahl der Schlüsselwörter in Java doch stark begrenzt. Außerdem dürfte die Fehlerquote (auch dank der IDEs) nicht sehr hoch sein.

Insofern finde ich das als Annotation schon in Ordnung, wobei ich deren optionale Verwendung nur als Kompromiss in Bezug auf Altcode sehen kann. In neuem Code gibt es überhaupt keinen Grund, darauf zu verzichten, nur muss das halt jetzt mit Tools zur statischen Codeanalyse überprüft werden. Der Programmierer bringt seine Intention zum Ausdruck und die wird vom Compiler dann auch gnadenlos durchgesetzt. Und wieder: Dank der IDEs/Editoren geht das heute eh automatisch.

 

[KonradN]

Unabhängig von den OFF Topic Elementen noch ein paar generelle Hinweise aus meiner Sicht zu dem @Override:

Bezüglich dieses @Override gibt es bei den statischen Codeanalyse-Tools auch entsprechende Regeln und auch Unterstützung bei IDEs:

• Statische Codeanalyse PMD: https://pmd.sourceforge.io/pmd-6.3.0/pmd_rules_java_bestpractices.html#missingoverride
• Eclipse bietet z.B. das automatische Hinzufügen: Properties > Java Editor > Save Actions : add missing @Override annotations

Das Überschreiben einer Methode ist ein aktiver Vorgang bei der Entwicklung. Da bieten Entwicklungsumgebungen in der Regel eine gute Unterstützung, d.h. man hat mit wenigen tastendrücken direkt die Methode mit Rumpf generiert. Da hat man dann automatisch auch das @Override.

Beim Lesen von Code ist dann auch direkt klar, dass die Methode halt etwas überschreibt. Das kann sinnvoll sein, um da z.B. nicht mal eben ein Refactoring am Namen machen zu wollen oder so. (Das ist ja ein Refactoring, das durchaus öfters angewendet wird.)

Und ehe ich da weiteres schreibe, hat da @mihe7 bereits das schön geschrieben, worauf ich dann im Anschluss auch noch hinaus wollte:

Insofern finde ich das als Annotation schon in Ordnung, wobei ich deren optionale Verwendung nur als Kompromiss in Bezug auf Altcode sehen kann. In neuem Code gibt es überhaupt keinen Grund, darauf zu verzichten, nur muss das halt jetzt mit Tools zur statischen Codeanalyse überprüft werden. Der Programmierer bringt seine Intention zum Ausdruck und die wird vom Compiler dann auch gnadenlos durchgesetzt. Und wieder: Dank der IDEs/Editoren geht das heute eh automatisch.