Programier-Noob will Poker-Programm schreiben

[Simon Moon]

Salute allerseits

Nun eigentlich wurmt es mich schon lange, dass ich nie den Einstieg in eine Programiersprache finde. Ich habs schon 2x mit Java und einmal mit Delphi probiert. Die Ansätze waren wohl auch jedesmal besser und langsam hab ich auch einige Konzepte grob verstanden und kann mit einigen Befehlen umgehen. Einfach Dinge sind grad knapp möglich.

Nun hab ich aber wieder mal ein halbes Jahr alles liegen lassen und will jetzt mit was neuem anfangen. Ziel ist ein einfaches Programm. In diesem Fall möchte ich zu beginn eigentlich nur eines entwerfen, wo ich die Karten, die ich habe, eingebe, und das mir die Chancen, welche ich mit dieser Karte habe, ausgibt. Ok, das ganze wird mir eine schöne Wissensexkursion in die Welt der Wahrscheinlichkeit noch bescheren, aber das lass ich mal auf mich zu kommen.

Nun ist es aber wohl vorallem wichtig, dass ich geplant vorgehe. Also Probleme auseinander nehme etc. Leider fehlt es bei mir genau bei diesem et cetera, da ich mir da kein Bild draus machen kann. Wie plant man eine Software?

Eine Weitere Frage die sich mir stellt, soll ich es nochmals mit Java probieren oder wäre Python nicht allenfalls auch geeignet?

Wäre froh über einige Hilfestellungen und Kritiken.

[Fruli-Tier]

Erstmal:
Suche Dir eine, genau eine Sprache und arbeite Dich da rein. Mit diesem oder jenem, oder wie wäre es vielleicht mit... kommst Du nicht weit. Hier ist eine Entscheidung nötig!

Zweimal:
Überleg Dir genau, was das Programm denn machen soll, soll heissen, überlege die komplette geplante Funktionalität.

Drittmaligst:
Überleg Dir hier nochmal gut, ob Du auch wirklich in der Lage bist, den Schuh zuzubinden um das ganze durchzuführen.

Ist die Idee Interessant genug bis zum Ende gesponnen zu werden?

Reichen die Sprachkenntnisse? Wenn nicht, bist Du bereit, so lange das Programm beiseite zu legen und zu üben, bis Du die nötigen Fertigkeiten besitzt?

Viertigst:
Ablaufplan erstellen: Was passiert wann, begonnen ganz am Anfang.

Beispiel:
Hauptmenu mit 3 Möglichkeiten => Neu, Laden, Ende
Was passiert, wenn ich auf Laden klicke? Was muss da alles gemacht werden?
z.B.

Dialog öffnen, um Dateinamen abzufragen
Überprüfen, ob Datei vorhanden
Datei auslesen
Spiel entsprechend widerherstellen

usw.
Einige dieser Punkte lassen sich dann evtl. nochmals aufspalten, das geht dann aber mehr in die Realisierung und ist hier nicht ganz so wichtig.

Zuletztigenst
Arbeite die einzelnen Punkte ab, bei größeren "Problemen" erstelle dir ein Struktogramm (http://de.wikipedia.org/wiki/Struktogramm), beispielsweise für das Laden und Wiederherstellen eines Spielstandes.

[Monger]

Java, Java, Java !!! *Gröhl* :D

Okay, jetzt habe ich mich grade als kompetenten Ansprechpartner disqualifiziert...

Egal. Das allererste was du tun solltest (so trivial es auch klingt) ist, dir Papier und Stift zu schnappen, und die Oberfläche aufzuzeichnen, und zwar inklusive aller Dialoge, aller Knöpfe, aller Fenster.

Das zweite was du tun solltest ist, genau aufzuschreiben was deine Software alles können soll. Dann hast du so eine Art kleines Pflichtenheft vor dir, was dir einen ganz guten Einblick davon gibt wie komplex die ganze Geschichte wird.

Es gibt immer ein paar Probleme die knallhart sind, und einige die nur Fleißarbeit sind. Bevor du anfängst das eigentliche Programm zu schreiben, solltest du zumindest einen ungefähren Lösungsweg für die schlimmsten Probleme haben. Sonst kann es passieren, dass du bei 90% dein gesamtes Programm nochmal auseinander pflücken musst, weil du eine wichtige Kleinigkeit übersehen hast.

Über Projektplanung könnten wir hier noch locker 100 Seiten reden, aber ich denke, die zwei Punkte sollten für den Anfang reichen.
Die größten Probleme stellen sich übrigens meistens dort ein, wo man sie im Kleinen nicht sieht. In der Signalisierung zum Beispiel: Wenn ich einen riesigen Klumpen aus hunderten von Objekten habe, wie sorge ich dafür dass jedes Objekt genau das mitkriegt was es wissen muss?
Wie sorge ich dafür, dass ich mein bestehendes Programm mal erweitern kann, ohne die Hälfte über Bord zu schmeißen? (In deinem Beispiel: wie definiert man die Spielregeln und Strategien möglichst zentral, ohne den Rest zu beeinflussen?)
Wie vermeide ich Dateninkonsistenz, wenn ich speichere und anschließend lade?

SOLCHE Fragen werden dir wahrscheinlich Kopfzerbrechen bereiten, nicht so sehr die Sprachsyntax.

[Trap]

Fruli-Tier[/POST]']Erstmal:
Suche Dir eine, genau eine Sprache und arbeite Dich da rein. Mit diesem oder jenem, oder wie wäre es vielleicht mit... kommst Du nicht weit. Hier ist eine Entscheidung nötig!

Da stimm ich dir zu.

Ansonsten ist das Software Engineering/Projektmanagement-Müll der in Realität mehr Lüge als Methode ist.

[Monger]

Trap[/POST]']Da stimm ich dir zu.

Ansonsten ist das Software Engineering/Projektmanagement-Müll der in Realität mehr Lüge als Methode ist.

Hey, Projekt Management bringt schon was! Es betreibt zwar keiner ernsthaft, aber nur weil Fehlplanung nur mit Fehlplanung korrigiert werden kann.

[Fruli-Tier]

Monger[/POST]']Egal. Das allererste was du tun solltest (so trivial es auch klingt) ist, dir Papier und Stift zu schnappen, und die Oberfläche aufzuzeichnen, und zwar inklusive aller Dialoge, aller Knöpfe, aller Fenster.

Braucht man denn, um sich anhand eines selbsterdachten Projektes das Programmieren beizubringen, unbedingt gleich eine GUI? Das halte ich Anfangs für absolut unsinnig.

[Fruli-Tier]

Monger[/POST]']Hey, Projekt Management bringt schon was! Es betreibt zwar keiner ernsthaft, aber nur weil Fehlplanung nur mit Fehlplanung korrigiert werden kann.Ich glaube, da hast Du was falsch verstanden.

[Monger]

Fruli-Tier[/POST]']Braucht man denn, um sich anhand eines selbsterdachten Projektes das Programmieren beizubringen, unbedingt gleich eine GUI? Das halte ich Anfangs für absolut unsinnig.
Ich eigentlich auch, aber wenn du nicht gerade irgendeinen Dienst schreibst, braucht nunmal jedes Programm irgendeine GUI.

Man muss (und imho sollte) nicht als Anfänger damit anfangen die GUI gleich zu Anfang zu programmieren, aber bei einem Top-Down Ansatz ist sie das erste worüber man nachdenken sollte.

[Fruli-Tier]

Die Console tut es doch zu Beginn genauso. Zudem hat man es hier selbst in der Hand, dass die Applikation nicht schon nach dem ersten mal asuführen wieder beendet wird. Fördert logisches Denken ohne dabei mit zuviel Code zu erschlagen.

[Monger]

Fruli-Tier[/POST]']Die Console tut es doch zu Beginn genauso. Zudem hat man es hier selbst in der Hand, dass die Applikation nicht schon nach dem ersten mal asuführen wieder beendet wird. Fördert logisches Denken ohne dabei mit zuviel Code zu erschlagen.

Wenn es dir nur um die Funktionalität geht: wenn man vernünftige Debugging Tools hat (die man ja sowieso haben sollte), brauchst du nichtmal in die Konsole zu gehen. Da empfinde ich die Konsole eher als nutzlose Einschränkung denn als Bereicherung.

[darph]

Fruli-Tier[/POST]']Die Console tut es doch zu Beginn genauso. Zudem hat man es hier selbst in der Hand, dass die Applikation nicht schon nach dem ersten mal asuführen wieder beendet wird. Fördert logisches Denken ohne dabei mit zuviel Code zu erschlagen.
Also wenn man gleich mit dem MVC (http://en.wikipedia.org/wiki/Model-view-controller) im Hinterkopf anfängt, sollte das prinzipiell doch kein Problem darstellen. Man macht erstmal die Konsolenapplikation und sorgt dafür, daß das Programm überhaupt läuft. GUI kann man dann später problemlos auf die definierte Schnittstelle aufsetzen.

[Fruli-Tier]

darph[/POST]']Also wenn man gleich mit dem MVC (http://en.wikipedia.org/wiki/Model-view-controller) im Hinterkopf anfängt, sollte das prinzipiell doch kein Problem darstellen. Man macht erstmal die Konsolenapplikation und sorgt dafür, daß das Programm überhaupt läuft. GUI kann man dann später problemlos auf die definierte Schnittstelle aufsetzen.Na ob das für einen Anfänger nicht schon allein vom Konzept her ein bisschen Over-Sized wäre? ;)

@Monger
Ich hab jetzt nicht so ganz verstanden worauf Du hinaus willst. Ich glaube, da sollten wir beide mal ein paar erläuternde Worte um unsere Gedanken hinzudichten. Vielleicht wirds ja dann transparent.

[Monger]

Fruli-Tier[/POST]']Na ob das für einen Anfänger nicht schon allein vom Konzept her ein bisschen Over-Sized wäre? ;)

Ist unser Threadersteller denn ein Anfänger? So wie ich ihn verstanden habe, hat er grob schon verstanden worum es geht, und will jetzt mal was sinnvolles machen.


@Monger
Ich hab jetzt nicht so ganz verstanden worauf Du hinaus willst. Ich glaube, da sollten wir beide mal ein paar erläuternde Worte um unsere Gedanken hinzudichten. Vielleicht wirds ja dann transparent.
Ja, irgendwie haben wir etwas Kommunikationsprobleme! :D

Mein Statement: Um Programme zu testen, braucht man keine Konsole, sondern eine gute Entwicklungsumgebung.
WENN man dann eine Bedienoberfläche will, dann gleich eine richtige GUI.

[Simon Moon]

Also, ok, das ganze hat mir einige Gedankenanstösse mal gegeben.

Nun, Ahnung hab ich im Prinzip von allem ein bisschen und von nichts richtig. Struktur ist mir an sich schon klar (also keine Imperativ Programmierung), aber es mangelt v.a. an der Syntax.

Hab schon an Brainfuck als Sprache nachgedacht - da müsste ich keine Befehle lernen, dafür alles einfach logisch durch denken. Aber bei dem Quellcode soll einer mal die Übersicht behalten.

Momentan schwanke ich wirklich noch zwischen Python und Java. Erstere soll ja nochmals etwas vereinfacht worden sein, hat aber wohl nicht so gute Dokumentationen.

Das Programm hab ich eigentlich so gedacht.
Anfänglich Konsollenbasiert: Ich geb Karte A, Karte B ein, Programm (P) spuckt wahrscheinlichkeit des Gewinns aus und will, dass ich den Flop (Karten C, D, E) eingebe. Danach erneute Ausrechnung der Chancen. P will den Turn eingegeben haben (Karte F). Wieder Ausgabe der Chancen. P will nun noch die River Card (Karte G) haben. Finale Ausgabe meiner Chancen.
Danach einfach eine simple GUI aufsetzen.
Später dann vll. sogar mit Bildererkennung fürs Online-Pokern, dass ich quasi beim Pokern immer live meine Chancen sehe, ohne was dafür zu tun ;)


Probleme in der Formel sind nun aber: A, B kann nur ich nutzen, Karten C - G können alle anderen auch nutzen, haben aber gleichzeitig auch noch zwei eigene Karten. Das Ganze wird imo schon allein Mathematisch recht fordernd (hatte nie Stochastik/Kombinatorik in der Schule :( )

[Monger]

Vielleicht denke ich da wieder um zu viele Ecken herum, aber imho sollte dein erster Schritt sein, den Kartenstoß nachzubilden. 52 Karten, vier Farben, Zahlen von Ass bis König...

Wenn du so weit bist, dass alle Karten eine Wertigkeit haben, kannst du anfangen dafür Statistik Funktionen zu basteln. Und danach all die Methoden die so ein Spiel braucht: Karte ziehen, Karte abwerfen... Bevor dir der Rechner deine Wahrscheinlichkeiten ausrechnen kann, muss er das Spiel erstmal verstehen und ein Stück weit auch spielen können...

Was du letztendlich dann daraus machst (bestimmte Szenarien durchspielen wie z.B so und so viel Karten ziehen, und dann Wahrscheinlichkeiten für verbleibende Karten voraussehen) muss ziemlich zuletzt kommen.

[Fruli-Tier]

Monger[/POST]']Ist unser Threadersteller denn ein Anfänger? So wie ich ihn verstanden habe, hat er grob schon verstanden worum es geht, und will jetzt mal was sinnvolles machen.
Grob Verstehen und kein Anfänger sein, sind bei mir 2 paar Sneaker.
Monger[/POST]']
Ja, irgendwie haben wir etwas Kommunikationsprobleme! :D

Mein Statement: Um Programme zu testen, braucht man keine Konsole, sondern eine gute Entwicklungsumgebung.
WENN man dann eine Bedienoberfläche will, dann gleich eine richtige GUI.
Da siehste, ich wollte ein Konsole als Ersatz für eine GUI benutzen, sprich, Interaktion ohne Mausklicks, sondern über die Eingabe einer Nummer, die einem vordefinierten und angezeigtem Menupunkt entspricht.

Dass das ganze in mit Hilfe einer IDE erstellt wird, das versteht sich von selbst. Soweit kommts noch, dass ich Kommandozeilenprogrammierung oder ähnliches vorschlage... ;)

Hab schon an Brainfuck als Sprache nachgedachtWTF?????


Ich geb Karte A, Karte B ein, Programm (P) spuckt wahrscheinlichkeit des Gewinns aus und will, dass ich den Flop (Karten C, D, E) eingebe. Danach erneute Ausrechnung der Chancen. P will den Turn eingegeben haben (Karte F). Wieder Ausgabe der Chancen. P will nun noch die River Card (Karte G) haben. Finale Ausgabe meiner Chancen.
Danach einfach eine simple GUI aufsetzen.
Später dann vll. sogar mit Bildererkennung fürs Online-Pokern, dass ich quasi beim Pokern immer live meine Chancen sehe, ohne was dafür zu tunWTF Nr. 2??? :D
Diese Art von Pokern ist für mich wie Chinesisch. Wahrscheinlich ist es schon das was ich auch kenne, aber komisch formuliert. Ist ja auch egal ;)
Das Ganze wird imo schon allein Mathematisch recht fordernd (hatte nie Stochastik/Kombinatorik in der Schule )
Ohne es selbst genau durchgesehen zu haben (http://de.wikipedia.org/wiki/Stochastik)Vielleicht denke ich da wieder um zu viele Ecken herum, aber imho sollte dein erster Schritt sein, den Kartenstoß nachzubilden. 52 Karten, vier Farben, Zahlen von Ass bis König...Das hört sich gut an. Eine Karte ist ein Objekt, wobei jede Karte gewisse gleiche Eigenschaften hat (=>Basisklasse) und alle genaueren Beschreibungen (z.B. Ass, Dame usw.) weiter Abstraktionsebenen bilden (=> abgeleitet von der Basisklasse und weiter spezialisiert).

[Monger]

Das hört sich gut an. Eine Karte ist ein Objekt, wobei jede Karte gewisse gleiche Eigenschaften hat (=>Basisklasse) und alle genaueren Beschreibungen (z.B. Ass, Dame usw.) weiter Abstraktionsebenen bilden (=> abgeleitet von der Basisklasse und weiter spezialisiert).

Ich glaube, man muss es gar nicht so kompliziert machen. Mit einem enum kann man das ziemlich schnell erschlagen. In den Sun Tutorials zu enum habe ich auch ein Beispiel für ein Kartenspiel gesehen. Natürlich vorausgesetzt dass sich unser Threadersteller jetzt für Java entscheidet! ;)

Das geht relativ fix. Das ganze drumherum wird natürlich schnell kompliziert, aber so hat man zumindest mal einen Ansatzpunkt, von wo man ausgehen soll. Zumindest das was sich ganz klar von einem Objekt aus der Realität ableitet (Kartenstoß, Stoß mit abgeworfenen Karten, der Spieltisch...), kann man durchaus schonmal als Objekt modellieren.

[PH4Real]

Ich glaube Du willst Texas Hold'em Poker spielen... deswegen diese ungewöhnliche Beschreibung. Und anscheinend willst Du es gar nicht selbst spielen, sondern ein Wahrscheinlichkeitsprogamm schreiben, was Dir aufzeigt, wie Du momentan stehst (doch hoffentlich nicht, um es beim Online Poker zu verwenden ;) ).

Damit hast Du aber erstmal nicht unbedingt ein Programmiertechnisches Problem, sondern eher ein mathematisches, da es doch schon etwas aufwendig wird.

Wenn Du das umsetzen willst, brauchst wie schon gesagt erstmal die Grundstruktur: die Farben und die Zahlen aus denen die Karten bestehen, sowie dann das Kartendeck, die Hand etc.
Das kann man sehr einfach mit Kartenobjekten machen, die zum Beispiel dann die Farben und Werte als Attribute haben (kann man mit Enums schön machen, wie schon gesagt). Dann brauchst Du das Deck und schließlich die Hand.

Schwieriger wird es dann schon bei dem "Handevaluator" (bei Texas Hold'em: Best 5 out of 7), der die beste Hand (5) aus 7 Karten bestimmen muss. Dazu natürlich die ganzen Wahrscheinlichkeitsrechnungen, wobei die sich in Grenzen halten werden. Dazu schau Dir am besten mal einschlägige Pokerseiten zu Texas Hold'em und/oder Wikipedia an. Bei http://en.wikipedia.org/wiki/Poker_probability_(Texas_hold_'em) sind eigentlich alle mathematischen Grundwerkzeuge gelistet die Du brauchst.

Viel Spaß damit, aber denk daran, dass Du privat bestimmt kein Handy oder PDA mitnehmen kannst :D.

[Fruli-Tier]

@Monger
Als einfachste Variante klar zu bevorzugen, es verbaut dabei aber die Möglichkeit, einer bestimmten Sorte von Karten (z.B. Pik) auch bestimmte Arten von Berechnungen zukommen zu lassen (wenn es vielleicht auch ein wenig an den Haaren herbeigezogen ist).

Aber das ist mal nicht unsere Entscheidung, das sollte der Programmierer selbst wissen/überdenken. Zumal ich selbst so auf die schnelle nicht wirklich einen tieferen Sinn sehe, für eine Karte zwanghaft ein Objekt erstellen zu müssen. Dazu fehlt mir der Überblick über die geplante Funktionalität (siehe mein WTF Nr. 2 weiter oben ;))

Jetzt interessiert mich erstmal, wofür sich Simon Moon entscheidet, Java oder WTF ;D

[PH4Real]

@Simon Moon:

Ich habe mir nochmal durchgelesen, was Du genau willst und es ist doch etwas einfacher ;). Du brauchst wirklich nur für deinen Teil Kartenobjekte, Deck, Hand und einen Handevaluator. Erstellt noch ein paar schöne Konstruktoren für deine Hände und Karten, so dass Du sie mit Strings wie "As Kc" füttern kannst. Das wird ja dann wahrscheinlich deine Eingabe sein.

Wenn Du nun 2 Karten im Pocket hast und den Flop dort liegen hast, iterierst Du einfach alle Möglichkeiten durch, die dein Gegner im Pocket haben könnte (also alle 52 Karten minus den 5 die Du kennst) und berechst jeweils, welche Hand gewinnen würde. So kannst Du deine Gewinnwahrscheinlichkeiten relativ einfach ausrechnen. Wenn dann der Turn und der River kommt, machst Du es genauso nur eben best 5 out 6 bzw. best 5 out 7 mit dem Handevaluator.

Du wirst feststellen, dass die beiden geschachtelten Schleifen (alle Farben, alle Werte;aber denk daran, dass "As Ks" gleich "Ks As" ist... das spart eine Menge Möglichkeiten ;)), die dann die Möglichkeiten durchiterieren ziemlich häufig durchlaufen werden, da es ziemlich viele Möglichkeiten gibt. Sprich, dein Handevaluator sollte relativ schnell sein bzw. intelligent programmiert sein. Die Sprache ist dabei relativ unwichtig bei der Geschwindigkeit, sondern dein Verfahren wird letzendlich über die Geschwindigkeit entscheiden.

Am besten fängst Du einfach mit der Sprache deiner Wahl an (ich würde aber schon eine Sprache wie Java oder C# nehmen, da Du Dich dann mit dem Problem an sich mehr beschäftigen kannst) und probierst darauf los die Grundeinheiten zu erstellen. :)

@Fruli-Tier: Deine Vererbungshierachie für die Karten klingt interessant, würde mich aber auch hier eher Monger anschliessen, da beim Poker zum Beispiel alle Farben gleich behandelt werden (nicht wie bei Skat ;) ) und auch die Karten alle gleich behandelt werden. Es sind also keine spezielle Operationen für Pik oder so erforderlich. Zumindest bei Texas Hold'em ist es so :D.

Man brächte natürlich nicht für eine Karte ein Objekt zu erstellen. Ich habe schon Handevaluator gesehen, die haben alles in Bitarrays berechnet, aber wirklich intuitiv und zum Einsteigen in die Programmierung geeignet ist das wohl eher nicht ;) (und soviel schneller war er dann auch nicht... also er war schon schneller aber ob ich jetzt 0.2 ms oder 0.4 ms auf mein Ergebnis warten muss ist dann auch egal).

[Fruli-Tier @ other PC]

PH4Real[/POST]'][...]ich würde aber schon eine Sprache wie Java oder C# nehmen, da Du Dich dann mit dem Problem an sich mehr beschäftigen kannst[...]
Sehe ich auch so, zudem so ziemlich jeder "Hampel" mit Java-/C-Code etwas anfangen kann, solltest Du mal Hilfe benötigen.
PH4Real[/POST]']@Fruli-Tier: Deine Vererbungshierachie für die Karten klingt interessant, würde mich aber auch hier eher Monger anschliessen, da beim Poker zum Beispiel alle Farben gleich behandelt werden (nicht wie bei Skat ;) ) und auch die Karten alle gleich behandelt werden. Es sind also keine spezielle Operationen für Pik oder so erforderlich. Zumindest bei Texas Hold'em ist es so :D.Wenn die Kartenwertigkeit wirklich so simpel ist, dann ist eine Vererbungshierarchie natürlich ein bisserl viel. Jedoch ist es mir egal, ob ich mal schnell eine Klasse schreibe, die ich dann recht einfach erweitern kann (der Vorteil, wenn auch ein Schluck mehr Arbeit zu Beginn). Das wiegt den Umstand, wenn ich mir sofort den einfachsten Weg - eben über den enum - vornehme aber auf, sollte dann evtl. doch auf Klassen umgestellt werden müssen, falls es doch mal komplexer wird.

[Monger]

PH4Real[/POST]']
@Fruli-Tier: Deine Vererbungshierachie für die Karten klingt interessant, würde mich aber auch hier eher Monger anschliessen, da beim Poker zum Beispiel alle Farben gleich behandelt werden (nicht wie bei Skat ;) ) und auch die Karten alle gleich behandelt werden. Es sind also keine spezielle Operationen für Pik oder so erforderlich. Zumindest bei Texas Hold'em ist es so :D.

Die Karte an sich sollte natürlich schon ein Objekt sein, aber für die Typen (Farbe und Wertigkeit) reicht imho ein enum völlig.

Außerdem ist ein enum in Java ziemlich mächtig. Du kannst da problemlos Methoden und Attribute ausformulieren, und sogar Interfaces implementieren. Das enum ist ja im Grunde auch nichts anderes als eine Sammlung als lauter statischen Objekten. Dementsprechend ist eine Umstellung von enum auf eine "echte" Klasse imho nicht so das Problem.


Aber wir können hier noch lange rumdiskutieren. Nicht wir wollen ja ein Pokerspiel programmieren, sondern unser Threadersteller! :D

[Fruli-Tier @ other PC]

Gut, in Java bin ich jetzt nicht sonderlich bewandert, Krankheit sei Dank (:() hab ich gestern sogar einen Java Vortrag auf Arbeit sausen lassen müssen.

[darph]

Fruli-Tier[/POST]']Na ob das für einen Anfänger nicht schon allein vom Konzept her ein bisschen Over-Sized wäre? ;)Möglich. Aaaaaaber sich das erstmal durchzulesen und zu implementieren (ist ja mit einer Konsolenapplikation schnell gemacht, 3 Klassen, keine 100 Zeilen Code und fertig ist der MVC-Taschenrechner) kann hier nur von Vorteil sein. Dann fällt es später leicher, Interfaces herauszurefaktorisieren, um dann, wenn das Programm läuft, die GUI zu entwickeln. Insbesondere bekommt man dann eine sauber aufgeteilte Struktur aufgezwungen.

Programm und GUI in einem Aufwasch zu programmieren, kann ziemlich häßlich werden.

[Fruli-Tier @ other PC]

darph[/POST]']Programm und GUI in einem Aufwasch zu programmieren, kann ziemlich häßlich werden.Das ist richtig, einen ähnlichen Ansatz verfolgen wir auf Arbeit auch. Können wir uns an diese Stelle darauf einigen, dass Simon Moon das für die nähere Zukunft auf seine To-Do Liste setzt? :D Vielleicht zuerst das eigentliche Programm samt Logik und danach bastelt er dieses Konzept und seine GUI aussen herum.