Fehlermeldung "Time is not abstract"

[Data]

Hallöchen,

bekomme folgende Fehlermeldung für meinen Code:
"Time.java:1: Time is not abstract and does not override abstract method compareTo(java.lang.Object) in java.langComparable
public class Time implements Comparable {
^
1 error"

Liegt das daran, dass ich noch kein Objekt erzeuge oder stimmt etwas Grundlegendes nicht mit meinem COde?

Und gleich noch eine Frage: das Programm soll beim Setzen der Zeit (Zeile 30-34) eine IllegalArgumentException auswerfen. Das müsste doch mit Zeile 8-19 abgefangen sein, oder muss ich das hier auch noch mal machen?

Bin dankbar für jede Hilfe!

public class Time implements Comparable {
    private int
      hour,          // 0 .. 23
      day,           // 1 .. 31
      month;         // 1 .. 12

    // allgemeiner Konstruktor
    // Falls die Wertebereiche für die Attribute nicht eingehalten werden,
    // wird eine IllegalArgumentException ausgeworfen.
    public Time(int hour, int day, int month) {
     this.hour = hour;
     this.day = day;
     this.month = month;
     if (hour > 23 || hour < 0 || day > 31 || day < 0 || month > 12 || month < 0)
       throw new IllegalArgumentException(
                        "ungültige Eingabe! Bitte überprüfen!" + "Stunde: " 
                        + hour +"Tag: "+ day + "Monat: "+ month);
    }
  

    // Standardkonstruktor
    // Datum und Uhrzeit werden auf den 01.01., 00:00 Uhr eingestellt
    public Time() {
      hour = 0;
      day = 1;
      month = 1;
    }

    // die Zeit einstellen
    // Falls die Wertebereiche für die Attribute nicht eingehalten werden,
    // wird eine IllegalArgumentException ausgeworfen.
    public void set(int hour, int day, int month) {
    }

    // liefert eine Zeichenkette, welche die Attributwerte enthält
    public String toString() {
      return "Datum: " + day + "." + month + "." + "Stunde" + hour + ":00";
    }

    // zur Implementierung der Schnittstelle java.lang.Comparable
    // vergleicht das aktuelle Time-Objekt mit dem übergebenen Objekt o
    // liefert einen Wert < 0, wenn das aktuelle Objekt kleiner als t ist
    //                    > 0, wenn das aktuelle Objekt größer als t ist
    //                      0, wenn das aktuelle Objekt gleich t ist
    // Laufzeitfehler, falls o nicht vom Typ Time ist
    public int compareTo(Time o) {
      int month2 = o.month;
      int day2 = o.day;
      int hour2 = o.hour;
      //Fall1
      if (month2 < month)
        return -1;
      //Fall2
      if (month2 > month)  
        return 1;   
      //Fall3
      if (month2 == month && day2 < day)
        return -1;
      //Fall4
      if (month2 == month && day2 > day)
        return 1;
      //Fall5
      if (month2 == month && day2 == day && hour2 < hour)
        return -1;
      //Fall6
      if (month2 == month && day2 == day && hour2 > hour)
        return 1;
      //Fall7
      return 0;
    }

    // vergleicht das aktuelle Time-Objekt mit dem übergebenen Objekt o
    // liefert true, wenn das aktuelle Time-Objekt gleich o ist, sonst false
    // Laufzeitfehler, falls o nicht vom Typ Time ist
    public boolean equals(Object o) {
      if (o == null)
        return false;
      if (this.month == 0 && this.day == 0 && this.hour == 0)
        return true;
    }
}

 

[byte]

Der Fehler kommt daher, dass Du das Interface Comparable nicht richtig implementiert hast. Du schreibst zwar eine Methode compareTo(), aber mit einer anderen Signatur als die im Interface. Dadurch überlädst du die Methode, anstatt sie zu überschreiben.

Die korrekte compareTo() aus dem Interface Comparable verlangt ein Object als Parameter. Du musst dieses Object dann in Deiner Implementierung erst auf Time casten.

Wegen der IllegalArgumentException: Generell musst Du dort eine Exception behandeln (mit try-catch), wo sie auftreten kann. Bei Dir wirft z.B. der Konstruktor die IllegalArgumentException. Das bedeutet, Du musst diesen Fehler immer dann behandeln, wenn Du ein Time-Objekt erzeugst. Die Methode setTime() sollte natürlich auch eine solche Exception schmeissen, wenn die Parameter falsch sind. Dann musst Du diesen Fehler natürlich auch behandeln, wenn Du die setTime() Methode aufrufst.

 

[clemson]

    // allgemeiner Konstruktor
    // Falls die Wertebereiche für die Attribute nicht eingehalten werden,
    // wird eine IllegalArgumentException ausgeworfen.
    public Time(int hour, int day, int month) {
     this.hour = hour;
     this.day = day;
     this.month = month;
     if (hour > 23 || hour < 0 || day > 31 || day < 0 || month > 12 || month < 0)
       throw new IllegalArgumentException(
                        "ungültige Eingabe! Bitte überprüfen!" + "Stunde: " 
                        + hour +"Tag: "+ day + "Monat: "+ month);
    }

außerdem hast du da einen denkfehler: du weisst zuerst deinen lokalen variablen die übergebenen zu, und überprüfst erst dann, ob diese werte eigentlich ok sind. richtig wäre es, zuerst auf die richtigkeit zu überprüfen, gegebenenfalls eine exception zu werfen, und erst dann die werte zuzuweisen.

 

[byte]

Stimmt, das ist mir beim ersten Blick gar nicht aufgefallen. Wobei das im Grunde dann auch egal sein sollte, weil das Objekt eh nicht erzeugt wird, wenn der Konstruktor ne Exception wirft.

 

[L-ectron-X]

Dadurch überlädst du die Methode, anstatt sie zu überschreiben.

Entschuldige, wenn ich dich korrigiere. Aber in diesem Fall ist das nur eine Definition der Methode.
Sie wird weder überschrieben noch überladen.
Von überschreiben spricht man, wenn eine Methode (mit genau der gleichen Signatur) aus einer Basisklasse (Superklasse) in der abgeleiteten Klasse wieder auftaucht.
Von überladen spricht man, wenn eine Methode mit unterschiedlicher Methodensignatur mehrmals in ein und der selben Klasse auftraucht.

 

[byte]

Das ist jetzt sicherlich eine Frage der Definition. Mag sein dass Du da recht hast.

Semantisch ist aber ein Interface nix anderes als eine abstrakte Klasse ohne Implementierung und Felder. Insofern kann man meiner Meinung nach auch statt implementieren auch überschreiben der Interface-Methode sagen. Schließlich kann man auch in beiden Fällen die Annotation @Override verwenden.

Überladen ist in diesem Zusammenhang vielleicht auch etwas unglücklich formuliert. Im Grunde versteht man darunter aber nur die gleiche Methode mit unterschiedlichen Parametern. Und das trifft ja in diesem Fall zu.

Naja, mag sein dass Du per Definition der Begriffe recht hast. Wobei auch fraglich ist, ob es da "die eine" Java-Bibel gibt, wo die Definition dieser Begriffe in Stein gemeiselt sind.

 

[L-ectron-X]

Nun ja, ich habs mal so gelernt... :wink: