Java Bruchrechner, Operatoren auf static setzen gute Idee?



  • Ich schreibe einen Bruchrechner, jetzt habe ich zwei folgende Möglichkeiten:

    Beispiel am Plus-Operator:

    Eine mögliche Lösung wäre das hier:

    public Bruch plus(Bruch b)
    {
    // umrechnen auf gleichen Nenner (noch nicht gemacht)
    return new Bruch(this.getGanz + b.getGanz, this.getZaehler + b.getZaehler, berechneterNenner);
    
    /* ich weiß, die umgerechneten Werte für Nenner und Zähler, damit das ganze den gleichen Nenner hat, müsste/ sollte ich noch in eine extra Variable schreiben, aber so ungefähr kommt das hin*/
    }
    

    Andererseits könnte ich die Rechenoperationen auch static machen, also z.B. so:

    public static Bruch plus(Bruch a, Bruch b)
    {
    // umrechnen auf gleichen Nenner (noch nicht gemacht)
    return new Bruch(a.getGanz + b.getGanz, a.getZaehler + b.getZaehler, berechneterNenner);
    }
    

    Danke für eure Hilfe! 🙂



  • Kommt immer auf die Anforderung an. Man kann nicht allgemein sagen ob static nehmen soll oder nicht.
    Viele sind aber eher der Meinung möglichst wenig statische Methoden zu verwenden.



  • Wahrscheinlich beides. Die nicht statische Variante könnte ich mir aber eher als void add(Bruch b) vorstellen.



  • Mechanics schrieb:

    Wahrscheinlich beides. Die nicht statische Variante könnte ich mir aber eher als void add(Bruch b) vorstellen.

    Beides in meine Klasse zu schreiben, hab ich noch gar nicht in Betracht gezogen. Wo du es sagst, macht es echt viel mehr Sinn, die nicht statische Methode auf void zu setzen, da diese ja direkt von einer Instanz aufgerufen wird.

    Danke, konnte was damit anfangen.

    Wirago schrieb:

    Kommt immer auf die Anforderung an. Man kann nicht allgemein sagen ob static nehmen soll oder nicht.
    Viele sind aber eher der Meinung möglichst wenig statische Methoden zu verwenden.

    Warum sollte man nur wenige statische Methoden verwenden? Ich glaube, es kommt zwar sowieso nur selten vor, dass diese Sinn machen, aber warum sollte man sie aktiv vermeiden?



  • In erster Linie wirfst du damit das Konzept der Objektorientierung über den Haufen. Statische Variablen/Methoden gehören dann zu einer Klasse und nicht mehr zu einem Objekt. Somit ist schon mal die Polymorphie weg.
    Es kann zu Problem bei Interfaces und Unit Tests führen.
    Und statische Methoden können von erbenden Klassen nicht überschrieben werden. (Wobei es hier Workarounds gibt)

    Was aber nicht heist, dass man sie gar nicht verwenden soll. Es gibt sie ja nicht grundlos. Nur sollte man vorher überlegen ob man sie nun wirklich statisch braucht.



  • Wirago schrieb:

    In erster Linie wirfst du damit das Konzept der Objektorientierung über den Haufen. Statische Variablen/Methoden gehören dann zu einer Klasse und nicht mehr zu einem Objekt. Somit ist schon mal die Polymorphie weg.
    Es kann zu Problem bei Interfaces und Unit Tests führen.
    Und statische Methoden können von erbenden Klassen nicht überschrieben werden. (Wobei es hier Workarounds gibt)

    Was aber nicht heist, dass man sie gar nicht verwenden soll. Es gibt sie ja nicht grundlos. Nur sollte man vorher überlegen ob man sie nun wirklich statisch braucht.

    Ok, danke. Das sind alles Sachen, mit denen ich zwar ansatzweise etwas anfangen kann, aber die ich noch nicht richtig verstehe. Werde es fürs Erste wohl so hinnehmen und statische Methoden möglichst vermeiden. Danke für deine Erläuterung 🙂



  • In dem Fall wären statische Methoden aber ok und von der API her wahrscheinlich auch angebracht. Man braucht hier weder Polymorphie noch Mocking für Tests usw.


Log in to reply