Taschenrechner mit Gui erstellen

[alim]

Hallo zusammen,
ich habe einige fragen zu einem kleinen Java-Projekt. Und zwar habe ich vor einen Taschenrechner zu programmieren, welcher über ein GUI bedienbar ist. Dazu habe ich zwei Klassen angelegt, eine für den Rechner und eine für das GUI. Hier schon mal mein Quelltext der Rechner-Klasse:

package de.chris.calculator.calc;

public class Calc {
    double input1;
    double input2;
    double output;
    String error = "Du kannst nicht durch Null teilen";

    public double addition(double input1, double input2) {

        output = input1 + input2;
        return output;

    }

    public double subtraction(double input1, double input2) {

        output = input1 - input2;
        return output;
    }

    public double multiplication(double input1, double input2) {

        output = input1 * input2;
        return output;
    }

    public double division(double input1, double input2) {
        if (input2 == 0) {
            //Fehlermeldung
        } else {
            output = input1 / input2;

        }
        return output;
    }
}

Ich möchte, dass in der GUI eine Fehlermeldung ausgegeben wird, wenn input2 bei division null ist, man kann ja nicht durch null teilen. Jetzt ist meine Frage wie ich die Fehlermeldung in die If-Funktion reinschreib. Kann man so einen Taschenrechner auch ohne Arrays programmieren? Die hatten wir noch nicht im Unterricht :/
Ich würde mich über eventuelle Lösungsansätze freuen. In dem GUI hab ich noch keinen Quelltext, außer die Buttons und Textfelder.

Meine zweite Frage ist (ich code in Eclipse IDE) Wie ich die GUI testen kann, also ob ich irgendwie ne Main Klasse schreiben muss, über die ich dann ein neues Objekt der Klasse GUI erstelle.
Ich hoffe meine fragen waren verständlich, im Voraus schonmal Danke für eure Antworten!

 

[Xyz1]

Die Logik sollte sich nicht um die Daten oder die UI kümmern (MVC), aber zurück zur Frage, Du musst den "calc" Methoden eine Referenz deiner GUI übergeben. Wie man die if Bedingung formuliert, weißt du ja schon, genau-so. Wenn der Wert 0 ist, findet die Division nicht statt und eine Fehlermeldung wird "angezeigt". Cheers.

 

[Xyz1]

So geht's aber auch (wenn die Signatur verändert werden darf) und habe Dir eine main-Methode hinzugefügt:

class Calc {
	double input1;
	double input2;
	double output;
	String error = "Du kannst nicht durch Null teilen";

	public CalcResult1 addition(double input1, double input2) {

		output = input1 + input2;
		CalcResult1 c = new CalcResult1();
		c.r = output;
		return c;

	}

	public CalcResult1 subtraction(double input1, double input2) {

		output = input1 - input2;
		CalcResult1 c = new CalcResult1();
		c.r = output;
		return c;
	}

	public CalcResult1 multiplication(double input1, double input2) {

		output = input1 * input2;
		CalcResult1 c = new CalcResult1();
		c.r = output;
		return c;
	}

	public CalcResult1 division(double input1, double input2) {

		CalcResult1 c = new CalcResult1();
		if (input2 == 0) {
			c.e = error;
		} else {
			output = input1 + input2;
			c.r = output;
		}
		return c;

	}

	public static void main(String[] arg) {
		System.out.println(new Calc().division(2, 0));
	}
}

class CalcResult1 {
	String e = null;
	Double r = null;

	@Override
	public String toString() {
		return String.format("CalcResult1 [%s]", e == null ? r : e);
	}
}

 

[kneitzel]

Ich sehe zwei Möglichkeiten:
a) Die Division ist nicht erlaubt, daher wirfst Du eine Exception. Division ist halt nur definiert für Werte != 0 bei dem Divisor. Somit ist eine Exception ok. Die GUI muss also nur die Exception fangen.
b) Also double hat auch einen speziellen Wert: NaN (Not a Number). Prinzipiell könntest Du also rein bei der Berechnung einfach Double.NaN zurück geben, wenn die Division ungültig ist. (Siehe auch https://de.wikipedia.org/wiki/NaN - das müsste man dann auch bei den anderen Operationen implementieren. Ist ein Parameter NaN, dann ist das Resultat auch wieder NaN!)

Generell würde ich NICHT eine Referenz auf die GUI übergeben. Du hast es extra getrennt und da willst Du keine solche Abhängigkeit. Wenn, dann könnte man eine Art "Callback" einbauen. Da kann dann eine GUI registrieren, wenn sie an sowas interessiert ist. (Also ähnlich den Events in der GUI Entwicklung.)

Wenn man da einen Fehler-Status machen möchte, dann würde ich das evtl. als Status des Rechners sehen. Der Rechner hat dann einen Fehlerstatus. Dann hätte man den Rechner in Form von Statusübergängen abgebildet und es gäbe den Fehler-Status. Dann hätte man das aber als Status, der dann klar definiert wäre mit Statusübergängen und so.

Und wenn man schon Konstanten definiert, dann ist es üblich, public static final zu verwenden und die Namen in UPPERCASE zu schreiben:
public static final String DIVIDE_BY_ZERO_ERROR_MESSAGE = "Du kannst nicht durch Null teilen";

 

[alim]

So geht's aber auch (wenn die Signatur verändert werden darf) und habe Dir eine main-Methode hinzugefügt:

class Calc {
    double input1;
    double input2;
    double output;
    String error = "Du kannst nicht durch Null teilen";

    public CalcResult1 addition(double input1, double input2) {

        output = input1 + input2;
        CalcResult1 c = new CalcResult1();
        c.r = output;
        return c;

    }

    public CalcResult1 subtraction(double input1, double input2) {

        output = input1 - input2;
        CalcResult1 c = new CalcResult1();
        c.r = output;
        return c;
    }

    public CalcResult1 multiplication(double input1, double input2) {

        output = input1 * input2;
        CalcResult1 c = new CalcResult1();
        c.r = output;
        return c;
    }

    public CalcResult1 division(double input1, double input2) {

        CalcResult1 c = new CalcResult1();
        if (input2 == 0) {
            c.e = error;
        } else {
            output = input1 + input2;
            c.r = output;
        }
        return c;

    }

    public static void main(String[] arg) {
        System.out.println(new Calc().division(2, 0));
    }
}

class CalcResult1 {
    String e = null;
    Double r = null;

    @Override
    public String toString() {
        return String.format("CalcResult1 [%s]", e == null ? r : e);
    }
}

Danke für deine Mühe!
Ich werde falls ich mit meinem Quelltext nicht weiterkomme deinen nehmen XD .
Liebe Grüße!

 

[Xyz1]

Die Division ist nicht erlaubt, daher wirfst Du eine Exception

Finde ich unschön, denn dann wäre die Logik in der UI.

Also double hat auch einen speziellen Wert: NaN

Auch unschön.

public static final

Warum "public" und je nach Kenntnisstand, muss er das auch nicht "final" machen.

Das mit den Callback/Events wäre eigentlich eine gute Idee!

 

[kneitzel]

Der Vorschlag mit der Exception ist doch unter dem Strich nicht anders als Dein Vorschlag mit der Rückgabe-Option "Fehler". Ob ich nun eine Exception abfange und den Fehler behandle oder ob bei der Rückgabe ein Fehler gesetzt ist und das ausgewertet werden ist bezüglich der Fehlerbehandlung kein Unterschied. Bei der Exception nutze ich aber halt Möglichkeiten von Java und muss da keinen eigenen Code schreiben. Das bietet Möglichkeiten wie z.B. die Exception da zu behandeln, wo ich es für richtig halte. Bei Dir müsste da erst sowas kommen wie: Wenn Fehler, dann gibt einen Fehler weiter zurück....

Daher sehe ich bei der Exception keinen wirklichen logischen Unterschied zu Deinem Codevorschlag.

Bezüglich NaN - das ist ja durchaus so gedacht, dass dies verwendet wird. Dafür ist das ja eigentlich auch eingeführt worden wenn man sich das auf Wikipedia durchliest. Aber ich muss gestehen, dass ich das bisher auch noch nie genutzt habe. Aber beim Lesen des Threads ist das halt etwas, das mir wieder eingefallen ist.

Die Idee mit den Callbacks ist auf jede Fall günstiger, als eine konkrete Implementierung kennen zu müssen oder gar extra ein eigenes Interface dafür zu bauen. Aber das dreht hier die Verantwortlichkeiten um. Es wird eine Aufgabe abgegeben und da wird einfach nur ein Ergebnis erwartet. Eine größere Logik sehe ich hier erst einmal nicht angebracht. Typische Anwendungsfälle wären ja Observer Pattern oder so ... Und das sehe ich weniger.

Bei so Konstanten ist das einfach etwas, das ich einfach als üblich bezeichnen würde. Ist generell unkritisch, aber ich würde gewisse Dinge einfach jedem ans Herz legen. Über das public mag man streiten, aber ein final würde ich auf jeden Fall setzen. Ähnlich wie bei Parametern einer Methode - die sind bei mir auch generell final. Daher halt die entsprechende Anregung.

Aber dein Code-Vorschlag scheint Anklang gefunden zu haben.

 

[Blender3D]

Warum "public" und je nach Kenntnisstand, muss er das auch nicht "final" machen.

So eine Variable macht nur als Konstante Sinn.
public static final String DIVIDE_BY_ZERO_ERROR_MESSAGE =
sonst wäre eine Zuweisung wie
DIVIDE_BY_ZERO_ERROR_MESSAGE = "Hubert";
möglich, was der Semantik des Variabel Name nicht gerecht wird.

 

[Xyz1]

Ich wette er kann noch gar nix mit den ganzen Schlüsselwörtern anfangen, dann kann er sie auch weglassen. (Oder direkt ein String-Literal returnen.)

Das mit den konstanten Strings als Attribute ist eh zum wahnsinn geworden.

 

[kneitzel]

Dieses Thema ist doch recht interessant - und jetzt wo man das etwas sacken gelassen hat, ist die Frage, über was wir hier überhaupt im Detail reden:
Wir rechnen hier mit double Werten. Bei Double-Werten ist eine Division by Zero kein "Fehler" sondern klar definiert:

public class Test {
    public static void main(String[] args) {
        System.out.println(1. / 0.);
        System.out.println(-1. / 0.);
        System.out.println(0. / 0.);
    }
}

Java folgt hier der IEEE 754 und die beschreibt dies auch ganz genau im Detail.

Wenn man da etwas drüber nachdenkt, dann ist es ja auch ganz normal, denn es existieren klare Regeln zur Rundung. Diese double 0 ist also ggf. nur eine gerundete 0. Und damit ist eine solche Unterscheidung sinnvoll. Macht also alles durchaus Sinn.

An dieser Stelle dann auch noch einen Hinweis bezüglich NaN: NaN != NaN!:

        System.out.println(0. / 0. == 0. / 0.); // NaN != NaN => false!
        // oder
        double x = 0. / 0.; // NaN
        System.out.println(x == x); // false

Hier wird false ausgegeben! Die Prüfung, ob x NaN ist, erfolgt mit x != x.

Und wenn ich hier den Diskussionsverlauf noch betrachte:
- Die Schlüsselworte bringen ja nun keine wirkliche Komplexität mit. Wenn er diese nicht kennt, dann sollte er diese nachlesen oder einfach nachfragen.
- Und was sich dann auch aufdrängt: die Fehlermeldung ist komplett am falschen Platz! Die konkrete Meldung ist Sache der GUI und hat daher in der Business-Logik nichts verloren (So ein Text kann evtl. nicht angezeigt werden. Wenn da ein altes Display simuliert wird mit den 8 Leuchtelementen pro Ziffer, dann ist die Ausgabe evtl. nur ein "- ERR -" oder so. Daher würde ich dann eher einen Error-Code erwarten:
Wenn man Konstanten nutzen wollte, dann wäre es sowas wie:
public static final int NONE = 0;
public static final int ERROR_DIVIDE_BY_ZERO = 1;
Aber bei so einer Aufzählung wird dann auch gleich deutlich: Es drängt sich ein Enum auf.

Wenn man also in der Business Logik NaN so behandeln will, dann will man das evtl. auch mit den (+/-)Infinity Werten machen...