Herangehensweise beim Programmieren

[Glaze]

Guten Tag liebe ZFXler,

Ich lerne seit Gestern C++ und hatte vorher nur Erfahrung mit Markup Languages wie z.B HTML,CSS und bischen PHP.
Als Übungsmaterial benutze ich dass Buch "C++ professionell lernen und anwenden" 5te Auflage 2010 von Ula Kirch Prinz.
Seitdem ich C++ lerne stellt sich mir immer die Frage wie es Programmierern gelingt , dass umzusetzen was sie wollen.
z.B ein Programmierer möchte ein Taschenrechner programmieren, und da ist der Haken.
Wie wissen Programmierer, wie sie an solch eine Aufgabe herangehen sollen (Codestruktur bzw. Aufbau des Programms)?
Und ein lauffähiges Programm ensteht so wie man es sich vorstellt?

Hoffe ihr könnt mir helfen :)

Mit freundlichen Grüßen
Max, 16 J.

[Chromanoid]

Man lernt Umsetzungsmuster kennen, verinnerlicht sie durch praktisches* Ausprobieren und setzt sie dann ein, um Neues zu schaffen. Programmieren kann man eigentlich nur richtig durch Programmieren lernen. Selbes gilt bestimmt auch für alle anderen schaffenden Tätigkeiten.

*wenn man das im Kopf kann, dann reicht das vermutlich auch :)[/size]

[CodingCat]

Dieser Post ist sehr lang und bisweilen abstrakt geraten. Wenn du mittendrin das Gefühl hast, dass er dir nicht hilft, lies ihn bitte trotzdem bis zum Ende, denn das Wichtigste kommt zum Schluss.

Dein Anliegen ist eine hochspannende Frage, auf die ich selbst seit langer Zeit eine Antwort suche. Es gibt wohl unzählige Bücher und Lehrer da draußen, die dir Konzepte wie Objektorientierung und Kapselung durch Geheimnisprinzip und Lokalitätsprinzip beibringen. Diese Konzepte sind heute sowohl in der Industrie als auch in der Lehre sehr verbreitet und sollen dir durch Konventionen und Vorschriften Leitlinien geben, nach denen du deine Gedanken zunächst in kleinere Einheiten (Teilsysteme), dann in noch kleinere Einheiten (Klassen/Objekte) und schließlich in Quelltext umordnen kannst. Ich kenne deinen Wissensstand nicht. Wenn du von all diesen Dingen noch nichts gehört hast, ist das vollkommen in Ordnung.

Mein Problem mit dem beschriebenen Ansatz ist, dass er vielerorts mindestens so viel Unnötiges wie Sinnvolles fabriziert. Ich gehe davon aus, dass dir diese Konzepte in deinem Buch in der ein oder anderen Form auf alle Fälle beigebracht werden. Vorgegebene Leitlinien verhindern zwar gegebenenfalls grobes Chaos, viel zielgerichteter und effizienter arbeitest du jedoch, wenn du die Gründe für diese Leitlinien verstehst und direkt nach diesen handeln kannst, anstatt auf den Leitlinien entsprechenden Umwegen umständlichen Code zu schreiben und dir damit ggf. selbst die einfachsten Wege zu verbauen.

Mein Rat ist deshalb, dir zunächst einfach zu überlegen, wie dein Programm funktionieren soll, und nicht, wie dein Programm aussehen soll. Mit etwas Erfahrung kannst du später im Optimalfall die Funktionsweise direkt in Programmcode umwandeln, der sich von einer einfachen informellen Beschreibung der Funktionsweise nur unwesentlich (durch die Grammatik der gewählten Programmiersprache) unterscheidet.

Die Quintessenz der oben genannten Konzepte ist eigentlich ganz einfach: Komplizierte Programme sind nicht nur kompliziert zu verstehen, sie sind auch kompliziert zu schreiben, kompliziert zu erweitern und kompliziert zu verbessern. Die Leistung der Konzepte besteht darin, die Einfachheit eines Programmes genauer zu charakterisieren und gezielt zu fördern. Das hört sich jetzt schwierig und abstrakt an, ist es aber eigentlich nicht. Wichtige Ideen sind zum Beispiel:

• Stets möglichst wenige Probleme auf einmal lösen. Die Lösung eines Problems kann zum Beispiel die Berechnung eines Wertes sein, oder die Ausgabe von Text. Um den Überblick zu behalten, würde man im Quelltext jeder Lösung eine eigene Funktion (oder jedem Problem eine Klasse) spendieren. Ein guter Grundsatz ist hier: Eine (Teil-)Aufgabe pro Funktion, eine Aufgabe pro Klasse. Was getrennt funktioniert, lässt sich auch getrennt verstehen, und vereinfacht somit die Entwicklung.

• Vieles, was am Anfang als großes komplexes Problem daherkommt, zerfällt bei näherem Hinsehen in viele sehr einfache Teilprobleme, die sich wie eben ausgeführt getrennt lösen lassen. Sind diese Teilprobleme erstmal gelöst, ergibt sich die Lösung des komplexen Ausgangsproblems oftmals durch einfache Kombination der Teillösungen (Aufruf der Teilproblem-Funktionen, Instanziierung der Teilproblem-Klassen)

• Es ist sehr hilfreich, wenn problemspezifische Programmteile unabhängig von anderen Programmteilen arbeiten und funktionieren. Natürlich sollte dich das nie von sinnvoller Zusammenarbeit mehrerer Programmteile abbringen. Gerade als Anfänger sind viele jedoch geneigt, das Programm wild durch verschiedene Teilbereiche springen zu lassen. Dann wird es mit der Zeit oftmals schwierig, den Ablauf des Programms zu überblicken. Bei Änderungen an einem Programmteil gehen dann leicht andere Programmteile kaputt. Im Optimalfall funktioniert Zusammenarbeit azyklisch, das heißt wenn ein Programmteil einen anderen benutzt, sollte letzterer nach Möglichkeit nicht auch direkt von ersterem abhängig sein.

• Konzentriere dich auf das genaue Problem und versuche nicht, möglichst allgemein alle Fälle abzudecken. In die Falle der übermäßigen Allgemeinheit tappen gerade objektorientierte Programme häufig, weil Objektorientierung gerne mit Wiederverwendbarkeit und Allgemeingültigkeit verbunden wird. Je mehr Fälle du abdeckst, umso komplizierter und schlussendlich fehlerhafter wird ein Programm, ohne dass es davon profitiert, weil du ja eigentlich nur ein konkretes Problem lösen wolltest.

Ich habe dich jetzt schon mit Leitlinien bombardiert, in der Hoffnung, dass diese sehr abstrakte Skizzierung dir diese einigermaßen plausibel erscheinen lässt und dir ein gewisses Gefühl dafür gibt, wodurch du dir die Arbeit leichter machen kannst. Ich selbst bin leider heute so weit von meinem Anfangsstadium weg, dass ich die Verständlichkeit des Geschriebenen darin nicht mehr objektiv beurteilen kann.

Unabhängig davon ist es aber vor allem Übung, Erfahrung und kritische Analyse durch dich selbst wie durch andere, die dir nach und nach die sinnvolle Implementierung immer größerer, komplexerer und vor allem robusterer Programme ermöglichen. Deshalb ist mein Rat am Ende wieder: Mach dir nicht zu viel Gedanken zum Programmaufbau, sondern versuche lieber direkt die Funktionsweise in Quelltext umzusetzen.

Überlege dir, was ein Taschenrechner leisten muss und wie er das leisten kann. Dann fange mit den Einzelschritten an, teste diese isoliert, und baue sie nach und nach zu einem Taschenrechner zusammen.

Mein Angebot an dieser Stelle: Halte uns über deinen Quelltext auf dem Laufenden, dann können wir versuchen, dir Anregungen zur Vorgehensweise und Hinweise zu verfügbaren Optionen zu geben. Wenn du das tust, beginne damit möglichst bald, denn je kleiner und unbedeutender dein Programm am Anfang ist, umso leichter haben wir selbst es, dir bei dessen Entwicklung zu folgen.

[Tiles]

Wie wissen Programmierer, wie sie an solch eine Aufgabe herangehen sollen (Codestruktur bzw. Aufbau des Programms)?
Und ein lauffähiges Programm ensteht so wie man es sich vorstellt?

Ich kann zwar kein C++, aber eigentlich ist es recht einfach. Das ist alles Erfahrung. Du fängst ja nicht beim Taschenrechner oder überkomplizierten Programm an, sondern baust im Grunde immer auf deiner Vorerfahrung auf. Bis runter zu Hello World. Nächster Schritt ist dann mal nen anderen Text zu nehmen, einen zweiten Befehl dazuzupacken um noch was anderes mit dem Text anzustellen und so weiter. Und im Lauf der Zeit werden deine Schöpfungen eben immer komplexer, und dein Wissen darüber welches Werkzeug in welchem Fall zu nehmen ist auch. Und je mehr du weisst um so mehr kannst du dann auch damit anstellen.

[Glaze]

Man lernt Umsetzungsmuster kennen, verinnerlicht sie durch praktisches* Ausprobieren und setzt sie dann ein, um Neues zu schaffen. Programmieren kann man eigentlich nur richtig durch Programmieren lernen. Selbes gilt bestimmt auch für alle anderen schaffenden Tätigkeiten.

*wenn man das im Kopf kann, dann reicht das vermutlich auch :)[/size]

Vielen Dank fürs Antworten!
Learning by doing , ohne es geht sowieso garnichts :)

Dieser Post ist sehr lang und bisweilen abstrakt geraten. Wenn du mittendrin das Gefühl hast, dass er dir nicht hilft, lies ihn bitte trotzdem bis zum Ende, denn das Wichtigste kommt zum Schluss.

Dein Anliegen ist eine hochspannende Frage, auf die ich selbst seit langer Zeit eine Antwort suche. Es gibt wohl unzählige Bücher und Lehrer da draußen, die dir Konzepte wie Objektorientierung und Kapselung durch Geheimnisprinzip und Lokalitätsprinzip beibringen. Diese Konzepte sind heute sowohl in der Industrie als auch in der Lehre sehr verbreitet und sollen dir durch Konventionen und Vorschriften Leitlinien geben, nach denen du deine Gedanken zunächst in kleinere Einheiten (Teilsysteme), dann in noch kleinere Einheiten (Klassen/Objekte) und schließlich in Quelltext umordnen kannst. Ich kenne deinen Wissensstand nicht. Wenn du von all diesen Dingen noch nichts gehört hast, ist das vollkommen in Ordnung.

Mein Problem mit dem beschriebenen Ansatz ist, dass er vielerorts mindestens so viel Unnötiges wie Sinnvolles fabriziert. Ich gehe davon aus, dass dir diese Konzepte in deinem Buch in der ein oder anderen Form auf alle Fälle beigebracht werden. Vorgegebene Leitlinien verhindern zwar gegebenenfalls grobes Chaos, viel zielgerichteter und effizienter arbeitest du jedoch, wenn du die Gründe für diese Leitlinien verstehst und direkt nach diesen handeln kannst, anstatt auf den Leitlinien entsprechenden Umwegen umständlichen Code zu schreiben und dir damit ggf. selbst die einfachsten Wege zu verbauen.

Mein Rat ist deshalb, dir zunächst einfach zu überlegen, wie dein Programm funktionieren soll, und nicht, wie dein Programm aussehen soll. Mit etwas Erfahrung kannst du später im Optimalfall die Funktionsweise direkt in Programmcode umwandeln, der sich von einer einfachen informellen Beschreibung der Funktionsweise nur unwesentlich (durch die Grammatik der gewählten Programmiersprache) unterscheidet.

Die Quintessenz der oben genannten Konzepte ist eigentlich ganz einfach: Komplizierte Programme sind nicht nur kompliziert zu verstehen, sie sind auch kompliziert zu schreiben, kompliziert zu erweitern und kompliziert zu verbessern. Die Leistung der Konzepte besteht darin, die Einfachheit eines Programmes genauer zu charakterisieren und gezielt zu fördern. Das hört sich jetzt schwierig und abstrakt an, ist es aber eigentlich nicht. Wichtige Ideen sind zum Beispiel:

• Stets möglichst wenige Probleme auf einmal lösen. Die Lösung eines Problems kann zum Beispiel die Berechnung eines Wertes sein, oder die Ausgabe von Text. Um den Überblick zu behalten, würde man im Quelltext jeder Lösung eine eigene Funktion (oder jedem Problem eine Klasse) spendieren. Ein guter Grundsatz ist hier: Eine (Teil-)Aufgabe pro Funktion, eine Aufgabe pro Klasse. Was getrennt funktioniert, lässt sich auch getrennt verstehen, und vereinfacht somit die Entwicklung.

• Vieles, was am Anfang als großes komplexes Problem daherkommt, zerfällt bei näherem Hinsehen in viele sehr einfache Teilprobleme, die sich wie eben ausgeführt getrennt lösen lassen. Sind diese Teilprobleme erstmal gelöst, ergibt sich die Lösung des komplexen Ausgangsproblems oftmals durch einfache Kombination der Teillösungen (Aufruf der Teilproblem-Funktionen, Instanziierung der Teilproblem-Klassen)

• Es ist sehr hilfreich, wenn problemspezifische Programmteile unabhängig von anderen Programmteilen arbeiten und funktionieren. Natürlich sollte dich das nie von sinnvoller Zusammenarbeit mehrerer Programmteile abbringen. Gerade als Anfänger sind viele jedoch geneigt, das Programm wild durch verschiedene Teilbereiche springen zu lassen. Dann wird es mit der Zeit oftmals schwierig, den Ablauf des Programms zu überblicken. Bei Änderungen an einem Programmteil gehen dann leicht andere Programmteile kaputt. Im Optimalfall funktioniert Zusammenarbeit azyklisch, das heißt wenn ein Programmteil einen anderen benutzt, sollte letzterer nach Möglichkeit nicht auch direkt von ersterem abhängig sein.

• Konzentriere dich auf das genaue Problem und versuche nicht, möglichst allgemein alle Fälle abzudecken. In die Falle der übermäßigen Allgemeinheit tappen gerade objektorientierte Programme häufig, weil Objektorientierung gerne mit Wiederverwendbarkeit und Allgemeingültigkeit verbunden wird. Je mehr Fälle du abdeckst, umso komplizierter und schlussendlich fehlerhafter wird ein Programm, ohne dass es davon profitiert, weil du ja eigentlich nur ein konkretes Problem lösen wolltest.

Ich habe dich jetzt schon mit Leitlinien bombardiert, in der Hoffnung, dass diese sehr abstrakte Skizzierung dir diese einigermaßen plausibel erscheinen lässt und dir ein gewisses Gefühl dafür gibt, wodurch du dir die Arbeit leichter machen kannst. Ich selbst bin leider heute so weit von meinem Anfangsstadium weg, dass ich die Verständlichkeit des Geschriebenen darin nicht mehr objektiv beurteilen kann.

Unabhängig davon ist es aber vor allem Übung, Erfahrung und kritische Analyse durch dich selbst wie durch andere, die dir nach und nach die sinnvolle Implementierung immer größerer, komplexerer und vor allem robusterer Programme ermöglichen. Deshalb ist mein Rat am Ende wieder: Mach dir nicht zu viel Gedanken zum Programmaufbau, sondern versuche lieber direkt die Funktionsweise in Quelltext umzusetzen.

Überlege dir, was ein Taschenrechner leisten muss und wie er das leisten kann. Dann fange mit den Einzelschritten an, teste diese isoliert, und baue sie nach und nach zu einem Taschenrechner zusammen.

Mein Angebot an dieser Stelle: Halte uns über deinen Quelltext auf dem Laufenden, dann können wir versuchen, dir Anregungen zur Vorgehensweise und Hinweise zu verfügbaren Optionen zu geben. Wenn du das tust, beginne damit möglichst bald, denn je kleiner und unbedeutender dein Programm am Anfang ist, umso leichter haben wir selbst es, dir bei dessen Entwicklung zu folgen.

Vielen Dank CodingCat für deine sehr ausführliche Antwort!
Bin von meinem Aktuellen Wissensstand her noch bei den Grundlagen, doch der Taschenrechner war als Beispiel gedacht.
Mit meinem Wissenstand wäre ich zurzeit nicht in der Lage ein Taschenrechner zu programmieren.
Jedoch denke ich, dass jeder Anfänger Probleme hat sein Vorhaben in Code umzusetzen was meiner Meinung nach dass schwierigste ist.

viel zielgerichteter und effizienter arbeitest du jedoch, wenn du die Gründe für diese Leitlinien verstehst und direkt nach diesen handeln kannst, anstatt auf den Leitlinien entsprechenden Umwegen umständlichen Code zu schreiben und dir damit ggf. selbst die einfachsten Wege zu verbauen.

Hier stimme ich ihnen vollkommen zu.
Es wäre in der Tat zumindest für mich einfacher wenn man Erklären würde warum die Leitlinien so sind wie sie sind , anstatt sie blind anzuwenden, so könnte man wie sie es erwähnt haben ein weniger umständlicheren ggf. effizienten Code schreiben.
Für Anfänger ist es auch schwer beim Programmieren überhaupt richtig anzufangen, da sie nicht Wissen wie/wann sie welche Elementaren Datentypen,Namen zu verwenden haben müssen.

Mein Angebot an dieser Stelle: Halte uns über deinen Quelltext auf dem Laufenden, dann können wir versuchen, dir Anregungen zur Vorgehensweise und Hinweise zu verfügbaren Optionen zu geben. Wenn du das tust, beginne damit möglichst bald, denn je kleiner und unbedeutender dein Programm am Anfang ist, umso leichter haben wir selbst es, dir bei dessen Entwicklung zu folgen.

Dies werde ich aufjeden Fall tun :)

Wie wissen Programmierer, wie sie an solch eine Aufgabe herangehen sollen (Codestruktur bzw. Aufbau des Programms)?
Und ein lauffähiges Programm ensteht so wie man es sich vorstellt?

Ich kann zwar kein C++, aber eigentlich ist es recht einfach. Das ist alles Erfahrung. Du fängst ja nicht beim Taschenrechner oder überkomplizierten Programm an, sondern baust im Grunde immer auf deiner Vorerfahrung auf. Bis runter zu Hello World. Nächster Schritt ist dann mal nen anderen Text zu nehmen, einen zweiten Befehl dazuzupacken um noch was anderes mit dem Text anzustellen und so weiter. Und im Lauf der Zeit werden deine Schöpfungen eben immer komplexer, und dein Wissen darüber welches Werkzeug in welchem Fall zu nehmen ist auch. Und je mehr du weisst um so mehr kannst du dann auch damit anstellen.

Mit Erfahrung wird dies denk ich erst einfacher.


Mit freundlichen Grüßen
Glaze

[ponx]

huhu Glaze,
wie CodingCat schon gesagt hat, ist es wichtig, das Problem in kleine Häppchen zerlegen zu können. Das ist das schöne an objektorientierer Programmierung, die dieses Konzept unterstützt. Ich weiß nicht, ob dein Buch darauf eingeht, aber ich kann für den Einstieg "C++ für Spieleprogrammierer" von Heiko Kalista empfehlen.

Wenn ich mit einem neuen Projekt anfange, dann hab ich am Anfang auch nur eine grobe Vorstellung, wie ich das mal aufbauen will. Ich fange dann sozusagen an, von innen nach außen zu programmieren, also ich fang mit den elementaren Sachen an. Wenn ich z.B. eine Adressverwaltung schreiben will, dann fang ich mit der Klasse für die Karteikarte an, und überlege mir, was die alles beinhalten soll. Dann kann man schonmal was tippen, ohne Angst haben zu müssen, dass es gleich wieder in die Tonne wandert. Und wenn ein paar elementare Sachen schonmal getippt sind, kriegt man dann langsam ein besseres Bild davon, was man als nächstes alles braucht (in unserem Fall irgendne Datenstruktur wo die Karteikarten dann reinkommen z.B.). Später kann man diese elementaren Sachen dann dank der objektorientieren Programmierung auch schnell anders anordnen, ohne wieder bei Null anzufangen. Mit neuen Anforderungen bzw Erkenntnissen schmeißt man später im Aufbau eh vieles wieder um, das gehört dazu. Also am Anfang nicht verzweifeln oder Angst haben, dass man da was macht, was nicht optimales Design ist. Wenn's funktioniert, ist schonmal gut. Umstrukturieren ("Refaktorisieren") kommt dann später und damit dann auch der Lerneffekt.

[simbad]

Ich habe hier so einen alten Schinken "Algorithmen und Datenstrukturen" von Niklaus Wirth. Darin sind eben allerlei Grundlagen beschrieben und eben besonders wichtig allgemeine Algorithmen und Datenstrukturen.
Komplexe Systeme lassen sich im allgemeinen soweit zerlegen, das man sie mit dieser Basis formulieren kann. Diese Basis sollte man weitgehend verinnerlicht haben, wie ein alter Bekannter mal sagte, das muss aus dem Rückenmark kommen.
Da nächste, was einem hilft seine Programme zu Strukturieren ist Abstraktionsfähigkeit. Manche Menschen machen das automatisch, andere müssen das lernen und manche lernen das nie.
Und dann sollte man selbst ein strukturiertes Arbeiten an den Tag legen.

Alles weitere ergibt sich durch üben/anwenden.

[pUnkOuter]

Algorithmen und Datenstrukturen sind zwar wichtig, reichen aber nicht aus, um ein komplexes Programm sauber strukturieren zu können. Sie werden eher bei den Implementationsdetails angewendet. Wichtig für die allgemeine Struktur sind eher Themen wie OOAD und Design Patterns.

Aber meistens beginnt man ja nicht bei null. Wenn man z.B. eine Engine einsetzt, dann kann man z.B. auf einem Example aufbauen. Meist verlangt solcher Fremdcode sowieso eine spezielle Herangehensweise, die man dann auch gleich im restlichen Gamecode so verwenden kann. Wenn die Engine z.B. alles mit Komposition macht, dann bringt es kaum was, im eigenen Code riesige Vererbungsstrukturen aufzubauen.

[NytroX]

Hallo,

allgemein gesehen sind 3 Herangehensweisen beliebt, top-down, bottom-up und up-down.

Top-down ist im Prinzip das, was hier beschrieben wurde.
Man kennt das Gesamtproblem und unterteilt es in kleine Happen.
Also beim Taschenrechner könnte man sagen, dass man einen Teil für die GUI braucht, und einen Teil, der die Berechnung übernimmt.
Dann geht man detaillierter vor: Die GUI braucht eine Anzeige und Tasten, die Berechnung soll z.B. +,-,*,/ unterstützen, dafür könnte man eigene Funktionen schreiben.
Usw. Am Ende hat man dann sein komplettes Programm.

Bottom-Up bedeutet, dass man mit den Einzelteilen anfängt, und dann das Gesamtkonstrukt zusammensetzt.
Z.B. könnte man die GUI programmieren, und später dann sich überlegen, wie das mit der Berechnung funktionieren soll und wie das alles zusammen passt.
Den Berechnungs-Teil könnte man dann so Programmieren, dass er wiederverwendet werden kann, z.B. könnte man eine Mathe-Library machen o.ä.
Dann baut man die später in das Taschenrechner-Gesamtprogramm ein.

Up-Down ist eine Kombination, d.h. man grenzt erst den Gesamtumfang ein und beginnt dann mit der Implementierung des kritischsten/kompliziertesten Teils.
Beim Taschenrechner könnte man also mit der Berechnung anfangen, da das der entscheidende Teil ist.
Oder, wenn man sich z.B. mit GUI-Programmierung bisher nie beschäftigt hat, damit anfangen.

Hier ein paar Links dazu:
http://de.wikipedia.org/wiki/Top-Down-_ ... -Up-Design
http://www.computerwissen-online.de/?pa ... ntent=2646

[BeRsErKeR]

Zum Beispiel Taschenrechner: Ich finde das eigentlich eine gute Wahl für den Anfang. Ich würde es aber nicht gleich grafisch aufziehen, sondern eher als Ausgabe im Konsolenfenster (also mit einfacher Eingabe und Ausgabe).

Grundlegend ist es ja das einfache EVA-Prinzip. Man gibt etwas ein, die Daten werden vom Programm verarbeitet und am Ende kommt was dabei raus.

Das Simpelste wäre zunächst ein einfacher Addierer. Man gibt die beiden Summanden ein und das Programm gibt die Summe aus. Wenn man sich das genau anschaut sind eigentlich nur 4 Operationen nötig:

1. Einlesen des ersten Summanden
2. Einlesen des zweiten Summanden
3. Addition beider Summanden / Berechnung der Summe
4. Ausgabe der Summe im Konsolenfenster

Diese 4 Operationen sind sehr simpel. Man muss nur Wissen, wie man einen Wert einliest, eine Addition durchführt und einen Wert ausgibt. Das findet man eigentlich in jedem Buch oder auch einfach bei Google und Co.

Wenn man damit fertig ist kann man dem Benutzer zum Beispiel eine Auswahl anbieten, welche Rechenoperation er durchführen muss (für den Anfang einfach Addition, Subtraktion, Multiplikation und Division). Die oben genannten 4 Operation bilden nun z.B. jeweils eine komplette Rechenoperation mit Ein- und Ausgabe ab und man könnte daher einfach eine Funktion für jede der 4 Rechenoperation schreiben. Diese wird je nach Auswahl des Benutzers aufgerufen und berechnet das Ergebnis und gibt es aus.

Nach und nach kann man dann ans Fein-Tuning gehen, z.B. prüfen ob der Divisor bei der Division 0 ist und in diesem Fall einen Fehler oder "nicht definiert" ausgeben.

Und so weiter geht es. Ob das nun der beste Weg ist einen Taschenrechner umzusetzen finde ich am Anfang gar nicht so wichtig, sondern eher die Tatsache, dass man einen Weg findet, der funktioniert.


Das ganze soll als Anregung dienen, wie man als Anfänger an sowas rangehen kann. Ohne viel Fachchinesisch, weil ich denke das erschlägt einen am Anfang eher, als dass es einem nützt. Mit solchen Dingen kann man sich später beschäftigen, wenn man erstmal eine gewisse Reife erlangt, wie man an Probleme herangehen kann.

[Merlin]

Also bevor du zu Programmieren anfängst überlegst du dir wie es Ablaufen soll.
Damit meine ich z.b.: Menü für den Taschenrechner aufrufen danach Berechnung.
Es ist ganz wichtig sich vor dem Programmieren den Ablauf zu Überlegen.
Wenn man sich den Ablauf vor dem Programmieren gut überlegt kommt der Code ganz von alleine.
Außerdem sollte man immer in kleinen Schritten Programmieren zuerst Berechnen und das Menü Programmiert man dann einfach dazu.