Objektorientiertes Problem mit kleinem Projekt

wanderameise123 schrieb:
> Die vorkommenden Klassen habe ich schon im voraus erarbeitet. Da wäre
> die GAME_ENGINE die die Logik implementiert und Berechnungen, etc...
> durchführt, das USER_INTERFACE, welches die Benutzereingaben
> entgegennimmt und schließlich der PLAYGROUND, der die Ausgabe übernimmt.
Aus meiner bescheidenen Erfahrung mit der Thematik:

Die Strukturierung klingt furchtbar nach dem, was man in der Schule von 
planlosen Lehrkräften im Informatikunterricht eingeprügelt bekommt.

Playground und User_Interface kannst du schlecht trennen, beides gehört 
zur Benutzerschittstelle. Auch ist es vermutlich Unsinn, die 
Benutzereingaben überhaupt noch durch eine Klasse zu würgen -- du 
arbeitest doch sicherlich Ereignisorientiert. Nutze die Ereignisse, die 
deine Umgebung dir bereitstellt, evtl. inklusive Validatoren und 
solcherlei.
Was macht Playground dann anders, als deine Formularklasse, die du 
ohnehin schon instantiierst?

Für die Logik -- ich kenne dein Spiel ja nicht... -- bieten sich 
meistens Zustandsautomaten an.

Richtig interessant für OOP, so als nicht ganz realitätsnahes, aber 
lehrsames Beispiel, wäre es so: Jedes Lebewesen im Spiel ist ein Objekt. 
Und diese Objekte können selbstständig feststellen, wer um sie herum 
lebt...
Du würdest dir dann auch automatisch Gedanken darüber machen, wer wen 
erzeugt und wer wen und auf welche Art wieder zerstört.

Implementiert werden soll Conways, somit wäre jede Zelle ein Objekt, und 
hätte eigenschaften wie tot oder lebendig und anzahl lebender nachbarn. 
Ok könnte man machen. Dann würde jede Zelle selbst berechnen, wie ihr 
nächster Zustand wäre oder?
Somit bleibt die Verbindung zum user interface. Dann wäre jede Zelle 
auch ein grafisches Element?zB ein rectangle.
Trotzdem muss eine übergeordnete instanz die elemente verwalten und zB 
auf die user eingaben reagieren?

stimmt, aber wenn ich die form missbrauche, dann geht die modularität 
flöten oder? angenommen das user interface soll austauschbar sein, wäre 
es falsch alles in der form unterzubringen!? Zudem kann ich die arbeit 
so aufteilen und jeder entwickelt unabhängig, wenn man es in eine extra 
klasse verlagern würde.

die frage ist dann nur wie die Austauschbarkeit der klassen 
untereinander passiert.

also danke erstmal, denke das klingt alles soweit ok und logisch. Aber 
im moment möchte ich gerne einen anderen ansatz verfolgen und würde 
gerne wissen was du davon hälst:

1

this->game       = gcnew Game_Engine();

2

this->playground     = gcnew Playground(game);

3

this->user_interface = gcnew User_Interface(game);

Ich habe die 3 klassen in der form1 instantiiert und eine Referenz der 
game engine an die beiden anderen klassen übergeben. So dient die game 
engine als austauschmodul. wäre das auch eine möglichkeit?

ja das ist mir auch aufgefallen, es fehlt die referenz in die andere 
richtung. keine ahnung, was wäre denn sinnvoll? es würde es gerne so 
umsetzen, da ich es schon soweit habe.

Vielleicht solltest du dich trotzdem von deiner Komposition (Referenzen 
rumreichen) lösen.
Was hälst du denn davon, eine abstrakte Klasse 'Game' zu implementieren, 
die virtuelle Methoden besitzt, um mit dem Benutzer zu reden?
Ein fertiges Spiel würde diese abstrakte Klasse dann ableiten und die 
virtuellen Methode vervollständigen.

das ist mir etwas zu hoch....

genau das ist nämlcih das Problem. Ich erstelle Klassen, die bestimmte 
Dinge erledigen. Ich stelle getter/setter methoden bereit um alles 
nötige zu kapseln. Letztendlich fehlt mir aber das Wissen, wie ich alles 
in Verbindung bringe und vernetze. Ich merke wie ich trotz Klassen, 
alles wieder zB sequentiell mache. Irgendwie unterschätzt man das Thema!

Schreib dein Programm doch einfach mal konventionell, also strukturiert.
Wenn du dabei das Gefühl hast, dass du was richtig Sauberes erarbeitet 
hast, weißt du, warum man OOP nicht braucht. Ich kenne viele Leute, die 
konventionell (also ganz ohne OOP) viel saubereren und leichter zu 
wartenden Quelltext produzieren, als andre mit OOP, Templates und was 
der Compiler noch so hergibt. Ist doch völlig ok.

Wenn du dabei das Gefühl hast, dass alles verkorkst daherkommt, siehst 
du vielleicht eher, wo OOP dir das Leben erleichtert. Ich kenne auch 
Leute, die mit OOP die dollsten Programme konstruieren, aber völlig 
aufgeschmissen sind, wenns um eine blöde verkettete Liste geht, die ohne 
OOP geschrieben wurde (GTK...).

Karl heinz Buchegger schrieb:
> Getter und Setter sind nicht das, warum man Klassen baut. Die sind ein
> notwendiges Übel. Die Power einer Klasse besteht in den restlichen
> Memberfunktionen, welche Arbeit die verrichten können. Wenn du nur
> Getter und Setter hast, hättest du auch Strukturen benutzen können, das
> wäre kaum ein Unterschied.

Pfui, da mischt der alte C Hacker wieder Ansi C mit rein :-)
(das ist ein Grund warum ich persönlich die Hybridsprache C++ nicht 
ausstehen kann, wenn man Code in die Hand kriegt ist das meist ein 
wüstes Gewächs aus klassischen C und Objektorientiertheit. Ich will hier 
keine Diskussion pro und Contra auslösen, nur mein persönliches Problem 
mit C++)

Wenn objektorientiert dann bitte richtig, Strukturen und allein 
rumstehende Daten gibts nicht mehr, wohl aber Klassen die ggf. nur Daten 
kapseln. (z.B. ein 2 oder 3 dimensionaler Punkt)
Insofern sind Getter und Setter kein notwendiges Übel.

Ansonsten hast Du natürlich recht, die eigentliche Arbeit wird nicht von 
Getter und Setter verrichtet.

Gruß :-)

U.R. Schmitt schrieb:
> Pfui, da mischt der alte C Hacker wieder Ansi C mit rein :-)
> (das ist ein Grund warum ich persönlich die Hybridsprache C++ nicht
> ausstehen kann, wenn man Code in die Hand kriegt ist das meist ein
> wüstes Gewächs aus klassischen C und Objektorientiertheit.
Das ist so abwegig auch nicht.
Mit BOOST hat sich das zwar geändert. Aber mit C++ alleine stehst du bei 
den meisten alltäglichen Aufgaben immer noch ziemlich dumm herum.
Eine Datei löschen? Da sind wir wieder bei ANSI C :-)

Sven P. schrieb:
> Eine Datei löschen? Da sind wir wieder bei ANSI C :-)

1

std::remove(foobar);

gut danke werde es mir mal anschauen.

... ... ... schrieb:
> Sven P. schrieb:
>> Eine Datei löschen? Da sind wir wieder bei ANSI C :-)
>

1

std::remove(foobar);

Ja, und std::remove() ist ganz klar reinrassiges C++. So mit errno und 
char-Zeiger :-)