Einzelnen Beitrag anzeigen

Der_Unwissende

Registriert seit: 13. Dez 2003
Ort: Berlin
1.756 Beiträge
 
#4

Re: Pokerprojekt realisierung

  Alt 28. Mär 2007, 14:08
Zitat von .chicken:
Also so wie ich das verstanden habe, soll ich für alle "Oberbereiche" eine eigene Klasse schreiben?
Hab da noch nicht so viel Erfahrung, das mach ich dann am besten jeweils iner eigenen Unit oder?
Ich würde sagen ja, aber das ist (vielleicht) eher Geschmackssache. Eine Unit für eine Klasse hat den Vorteil, dass Du halt nicht schauen musst wo eine Klasse anfängt und eine andere endet, ist also einfach besser lesbar und damit leichter verständlich/wartbar/erweiterbar/...
Was die Oberbereiche angeht, so stimmt das, die kommen in eine Klasse, aber die können natürlich selbst wieder aus anderen (kleineren) Klassen zusammengesetzt werden. An sich ist die Idee der OOP (Objekt Orientierten Programmierung), dass eine Klasse ein bestimmte Problem löst. Man versucht dabei möglichst allgemeine Probleme zu lösen, nicht nur sehr spezielle Fälle. Das ganze realisiert man durch Abstraktion und kann dann eben die Lösung eines sehr abstrakten Problems für sehr viele unterschiedliche Fälle verwenden.

Zitat von .chicken:
Und den Server also ohne extra Form und auch ne eigene Klasse?
Genau!

Zitat von .chicken:
Also habe ja vor längerem schonmal angefangen ein Pokerspiel zu programmieren, allerdings hatte ich da noch keine Netzwerkfunktion und so eingeplant, sondern mich vorerst nur mit der Darstellung der Karten und dem Abfragen der Hände beschäftigt.
Deswegen bin ich nun etwas ratlos, wie ich das alles realisieren soll, is für mich schon ein etwas größeres Projekt
Und genau hier kann man leicht zeigen, warum diese Trennung sinnvoll ist. Vieles von dem was Du schon hast möchtest Du sicherlich wieder verwenden. Hast Du jetzt schon die Trennung zwischen Modell, View und Controller, so werden nur Anpassungen am Controller notwendig. Wie Karten, Geld, wer dran ist, ... dargestellt werden ändert sich nicht. Auch das speichern der Daten (was für Eigenschaften hat ein Spieler) ändert sich nicht. Sogar am Controller bleibt vieles gleich. Er muss weiterhin zwischen Daten und VIew vermitteln. Allerdings wird er einfach um bestimmte Ereignisse erweitert, die dann die Netwerkereignisse betreffen. Ok, dass View muss auch ein wenig erweitert werden, da hier zwischen aktivem Benutzer und inaktiven Benutzer unterschieden werden muss. So kann man dem View wie gehabt mitteilen, was gerade für eine Aktion statt findet (wer setzt wieviel, ausgeben der Karten, ...) aber natürlich darf der Spieler nicht die Karten anderer sehen oder für andere setzen, etc. Hier sollte es dann also ein Ereignis geben, dass mitteilt, dass das Formular gerade dem aktiven Spieler zugeordnet ist. Dann kann das Form entsprechende Möglichkeiten (call, pass, raise, ...) anzeigen. Die Aktion wird dann wiederum dem Controller gemeldet, der passt die Daten an und benachrichtigt über das Netzwerk alle bekannten Spieler.
Wie Du vielleicht bemerkt hast blieb das Modell wirklich völlig außen vor. Auch die Änderungen um etwas zu erweitern halten sich bei sauberer Modellierung immer in Grenzen.

Alles was Du tun must ist dazu Dein Problem (das gesamte Pokerspiel) in kleinere Teilprobleme zu zerlegen (z.B. Darstellung der Karten, Spieler, Steuerung, ...). Unterprobleme kannst Du dann noch weiter zerlegen, so besteht ein Spieler aus verschiedenen Eigenschaften, kann aktiv sein oder warten, kann callen, erhöhen, ... Hier findest Du vielleicht wiederum Probleme, die unabhängig voneinander sind (z.B. das Speichern der Daten vom Spieler und die Anzeige Selbiger). Dein eigentliches Projekt baust Du dann einfach aus den Lösungen dieser kleinen Probleme zusammen. Das hat den Vorteil, dass Du sehr leichte/kleine Probleme hast, die kann man viel besser überschauen, testen und entwickeln. Das gibt dann weniger Fehler und ist leichter wartbar.
Zudem kannst Du wenn Du das Programm erweiterst immer vieles wiederverwenden. So kann es reichen, dass Du einen solchen kleinen Teil austauscht oder erweiterst, manchmal sind es auch mehrere, aber selten oder nie alle. Hast Du hingegen eine große Unit, in der alles drin steht, dann musst Du natürlich direkt die Unit bearbeiten, die alles enthält. Gibt es hier Abhängigkeiten sind die schwerer zu berücksichtigen und Änderungen haben schnell viel größere Auswirkungen. Da ist es dann schwer den Überblick zu haben.

Gruß Der Unwissende
  Mit Zitat antworten Zitat