Wie programmiert man einen Taschenrechner in Java?

vram78

Lieutenant
Registriert
Dez. 2015
Beiträge
717
Hallo,

Also man sagt ja immer, dass man stets versuchen soll und eben üben soll, bis es klappt. Aber ich bekomme es nie hin:

Java:
[CODE]package me.taschenrechner.de;

import java.awt.geom.Path2D;
import java.awt.geom.PathIterator;
import java.awt.geom.Point2D;
import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.nio.file.WatchEvent;
import java.security.spec.DSAGenParameterSpec;
import java.sql.Types;
import java.text.Format.Field;
import java.util.concurrent.RecursiveTask;

import javax.print.attribute.standard.PrinterIsAcceptingJobs;
import javax.swing.DebugGraphics;
import javax.swing.GroupLayout.Alignment;
import javax.swing.text.StyledEditorKit.AlignmentAction;
import javax.swing.tree.VariableHeightLayoutCache;

import org.omg.CORBA.Any;
import org.omg.DynamicAny.DynAnyFactoryPackage.InconsistentTypeCode;
import org.omg.DynamicAny.DynAnyFactoryPackage.InconsistentTypeCodeHelper;
import org.omg.PortableInterceptor.SYSTEM_EXCEPTION;

public class Taschenrechner {

    private static final Object s = null;
    private static final int arg0 = 0;
    private static final Object Taschenrechner = null;
    private static PathIterator pi;

    public static void main(String[] args, Point2D r, type DSA) {
        
        boolean reader = new BufferedReader(new InputStreamReader(System.in)) != null;
        
        
        reader = false;
        
        
        Object w = s;
        Object a = w;
        
        System.out.println(reader);
        
        
        InconsistentTypeCodeHelper.insert((Any) a, null);
        AlignmentAction.SMALL_ICON.charAt(arg0);
        
        void TS(char x, int m, char y, int n) {
               int i, j;

              
               for (j = 0; j <= n - m; ++j) {
                  for (i = 0; i < m && x[i] == y[i + j]; ++i);
                  if (i >= m)
                     System.out.println(j);
               }
            }
        
        
    
        
        
        
        Path2D.contains(pi, r);
        PrinterIsAcceptingJobs.NOT_ACCEPTING_JOBS.ACCEPTING_JOBS.clone();
        
        Object type;
        
    }

    private static void DSAGenParameterSpec(Object type) {
        
        
    }

private static Object s(Object a) {

return null;
}

}
[/CODE]




Kann mir jemand Tipps geben, wie man sich das Wissen für sowas am Besten aneignet, weil ich mache irgendetwas stets falsch.


MFG
 
Man eignet sich sowas schritt für schritt an.
Auf welchen Wissensstand stehst du den? Hast du schon die ganzen basics durch?

Ich persönlich würde ja nen taschenrechner so nicht programmieren, woher hast du den Code her?
 
Fujiyama schrieb:
Auf welchen Wissensstand stehst du den? Hast du schon die ganzen basics durch?
Ja also bin jetzt bei der Objektorientierung

Fujiyama schrieb:
Ich persönlich würde ja nen taschenrechner so nicht programmieren
Hmm. ja, ich wusste irgendwie ich mache was falsch. Wie würdest du einen Taschenrechner programmieren?
 
Vermutlich würde ich Methoden mit den einzelnen Rechenarten Anlegen. Und dann noch bei bedarf ne GUI erstellen. Gibt aber bestimmt noch andere (einfachere) Möglichkeiten das umzusetzen.
Am besten mal ein Tutorial durchmachen, gibt ja unzählige davon wenns um das Beispiel "Taschenrechner" geht.
 
  • Gefällt mir
Reaktionen: DerTiger
@vram78 Geh doch erstmal ganz ohne Code vor. Denk darüber nach was dein Taschenrechner können soll. Da kann man ja mit kleinen Sachen anfangen, Tasten 0..9 und Grundrechenarten +, -, * und /. Das ist ja soweit klar. Dann überlegst du dir wie du die Eingabe brauchst und was bei den einzelnen Klicks passieren soll. Orientieren kannst du dich ja an Standard Rechnern in Windows oder Linux. Daraus baust du dir dann Pseudocode und überlegst dir, wie der Code aufgebaut sein müsste. Also effektiv: was musst du wann aufrufen (z. B. bei welchem Buttonklick soll was genau passieren), wie speicherst du die aktuelle Zahleneingabe zwischen, etc. pp.

Erst dann setzt du deinen Pseudocode in Java um. Wie du das dann machst (z. B. "Wie führe ich eine Methode bei einem Button-Click Event aus") kannst du dir per Recherche aneignen. Bei detaillierten Fragen helfen wir dann wenn du partout nicht weiterkommst, dabei dann bitte die entsprechende Codestelle mitliefern.

Wichtiger Rat:
Fange nicht zu fortgeschritten an, wenn du davon überfordert bist. Ein Taschenrechner kann sehr schnell sehr komplex werden. Wenn du mit Java auch nicht sattelfest bist ist das eine weitere Komponente, die dich schnell überfordern kann. Daher erstmal die Grundproblematik des Aufbaus fertig machen und wenn du weißt was du theoretisch machen musst dich an die praktische Umsetzung setzen. Das funktioniert wesentlich besser :)
 
  • Gefällt mir
Reaktionen: Sonnenkarma, LencoX2, DerTiger und 3 andere
Würde auch wie Fujiyama vorgehen.
Erst mal klein anfangen, Grundfunktionalität herstellen, bevor ich GUI mache.
 
vram78 schrieb:
Ja also bin jetzt bei der Objektorientierung


Hmm. ja, ich wusste irgendwie ich mache was falsch. Wie würdest du einen Taschenrechner programmieren?

Liest sich leider so, als hättest Du das oben irgendwo her kopiert.

Oben sind schon Anregungen, ich habe nicht das Gefühl, dass Du dich bereits ernsthaft mit dem Thema auseinandergesetzt hast, geschweige denn ein eigenes, konkretes Beispiel hast ( Du möchtest es von Grund auf vorgekaut haben, kann das sein ? ).

"Ich bin jetzt bei Objektorientierung ... " na gut, Java baut nun im Kern auf diesem Konzept auf, diese Aussage ist nun auch nichts hilfreiches.
 
maxpayne80 schrieb:
Du möchtest es von Grund auf vorgekaut haben, kann das sein ?
Ich verstehe die Schlussfolgerung nicht. Ich habe gelernt, dass man stets mit dem Prinzip Learning by Doing sich Inhalte aneignet.
 
Ja, stimmt auch.
Die Reihenfolge ist aber auch hilfreich und wichtig. Siehe Beitrag von @Nero1 .

Fang immer mit den Anforderungen an.

Separiere Verantwortlichkeiten. Trenne fachliche Logik von Darstellung und Mensch Maschine Schnitttelle.
Fang dann erst mit kodieren an
 
vram78 schrieb:
Ich verstehe die Schlussfolgerung nicht. Ich habe gelernt, dass man stets mit dem Prinzip Learning by Doing sich Inhalte aneignet.
Learning by doing klingt zwar ganz nett, gelebt wird es aber meist als "not understanding but botching" was man deinem Code auch ansieht. Schon bei den Imports fällt das auf.

Geh zurück zu start und mach alles was du bisher gemacht hast nochmal. Jedoch solltest du bei jedem Schritt den du machst folgende Fragen beantworten:
  • Was mache ich?
  • Wieso mache ich es?
  • Was macht der Code?
  • Wieso macht der Code das?
  • Ist das zum Lösen des Problems notwendig?

Das fehlt in den meisten Programmierkursen leider vollends, dass die Lernenden auf Verständnis getrimmt werden.

PS: Ich möchte meine tiefe Abneigung gegenüber AWT zum Ausdruck gebracht haben. Es gibt zum Bau von GUIs modernere und schönere Frameworks/Bibliotheken. Schaut euch bitte dringend an, wie (ver)alt(et) eure Lehrmaterialien sind.
 
Piktogramm schrieb:
dass die Lernenden auf Verständnis getrimmt werden.
Und wie macht man das am Besten, dass man das Verständnis dafür bekommt? Mir sagten sehr viele, u.a hier im Forum ,,Learning by Doing", was ich auch mache, aber irgendwie funktioniert es halt nicht.
 
Jede brauchbare Programmiersprache, jede brauchbare Bibliothek und jedes brauchbare Framework hat eine Dokumentation. Es läuft auf ein klassisches "RTFM" (Read the fucking manual) hinaus.

Ein Ansatz wäre also, bei deinem Programm jede Zeile durchzugehen und obige Fragen anhand der Dokumentation abzuarbeiten. Ich würde dabei empfehlen, dass du dir ein simpleren Quelltext suchst. Bei dem was du hier präsentiert hast würde ich nach dem 3. oder 4. Import ausrasten :). Ein Simples "Hello World" ist ganz sinnvoll, wenn du das erstemal in die Doku schaust.

PS: Jaja, ich weiß, das ist aufwendig. Das Ziel ist ein Gespühr zu entwickeln, irgendwann liest man nicht mehr alles nach, weiß aber im Zweifelsfall wie man notwendige Informationen findet. Das ist hilfreicher als nur zu erlernen wie man Quelltextfragmente unwissend zusammenkopiert..
 
  • Gefällt mir
Reaktionen: vram78
Piktogramm schrieb:
Jede brauchbare Programmiersprache, jede brauchbare Bibliothek und jedes brauchbare Framework hat eine Dokumentation
Mit Dokumentation meinst du wahrscheinlich das hier, oder?:
1607626589288.png
 
Soll das denn ein Konsolen- oder GUI-Taschenrechner werden? In deinem Code ist ja alles vertreten. Ich würde von 0 anfangen und nur das übernehmen, was auch mit dem angedachten Taschenrechner zu tun hat.
 
  • Gefällt mir
Reaktionen: Piktogramm
Das ist zumindest die Kurzdokumentation in Javadoc, aber du bist viel zu tief drinnen.

Die erste Zeile lautet ja "package ..." und danach geht es mit der Eskalation von zig imports weiter. Wäre also notwendig "package" "import" und danach die 9001 importierten Bibliotheken nachzuschlagen..

Und je nach IDE gibt es oft auch die Chance direkt zur Implementierung von Funktionen/Methoden zu springen. Da geht teils auch für Imports.
 
  • Gefällt mir
Reaktionen: vram78
vram78 schrieb:
Mit einer grafischen Oberfläche
Dann würde ich damit anfagen. Bau dir erst mal die GUI zusammen, der nächste Schritt wäre dann die Eingaben zu behandeln.
 
Das seh ich nun wieder genau andersherum. Es geht doch primär um den Taschenrechner -- exakt WIE das Ding auf den Bildschirm kommt ist, für den TR, erstmal nebensächlich.

Für OO immer erstmal mit der Modellierung anfangen. Was will ich, was hab ich, was brauch ich, und wie muß das interagieren?

Da könnte man zB mit einer abstrakten Klasse "Taste" anfangen und dann Klassen "Ziffer", "Speichern", "Operation" oder was was ich davon ableiten.

Man könnte eine statische Klasse Display erfinden.

Man könnte ein Ausnahmemodell entwickeln wo drinsteht was Fehler sein sollen. Sagen wir "Division durch 0". Oder einfach "Wert zu klein oder zu groß für den Taschenrechner".

Wenn man das erstmal HAT, dann kann man dieses Paket ins Backend eines GUI Taschenrechners stecken, oder eines Konsolen-Rechners, oder sogar eines scriptfähigen noninteraktiven Rechners.
 
Das wäre die Herangehensweise für jemanden mit Erfahrung. Der TE hat gerade erst mit Java angefangen. Mit der GUI sieht er den ersten (schnellen?) Erfolg. Danach kann man ja alles erweitern und umbauen.
 
Zurück
Oben