Die Situation ist folgende:

Es geht darum, in einem Strategiespiel die Karte zu verwalten und anzuzeigen. Dazu habe ich eine abstrakte Basisklasse Map, von welcher verschiedene Map-Arten abgeleitet sind / sein können. Darunter ist eine Klasse LayeredMap, welche aus verschiedenen Schichten besteht (Sie enthält Objekte von verschiedenen Unterklassen der Klasse MapLayer).
Des weiteren gibt es eine Klasse MapObject, welche die Darstellung einer Karte auf dem Bildschirm repräsentiert. Es soll möglich sein, mehrere MapObjects zu der selben Karte gleichzeitig zu haben.

Nun ist es so, dass die Art, wie ein bestimmter Kartentyp angezeigt wird, auch variieren kann und möglichst einfach neue Möglichkeiten hinzugefügt werden sollen. Deswegen habe ich eine abstrakte Klasse MapDrawer eingeführt, deren Unterklassen dann konkrete Map-Typen auf konkrete Art zeichnen können sollen. Dabei soll sowohl der Map-Typ als auch die Zeichenart variieren. Der MapDrawer, der die Layered-Maps nun zeichnet, hat wieder eine Liste von Objekten, abgeleitet von LayerDrawer, welche je ein einzelnes Layer zeichnen können, damit man möglichst einfach ein neues Layer zu der LayeredMap hinzufügen kann. Außerdem gibt es noch eine Abstrakte Basisklasse MapAccessor, welche die Umrechnung der Bildschirm in Map-Koordinaten für verschiedene Draw Modi übernimmt. Auch hiervon enthällt das MapObjekt eines.

Soweit, so gut, dies erscheint mir irgendwie recht kompliziert, geht das einfacher?

Aber das eigendliche Problem ist, wie stelle ich jetzt sicher (möglichst ohne noch mehr verschiedene Klassen), dass ein MapObject nur zueinanderpassende Maps, MapDrawer und MapAccessor enthalten kann? Hierbei wird die Situation dadurch verkompliziert, dass es verschiedene MapDrawer für jede Unterklasse Map gibt, dann aber MapAccessor, die nur von der Art von MapDrawer abhängen, nicht aber von der Map (ein bestimmter MapAccessor kann mit mehreren MapDrawern, die zu verschiedenen Unterklassen von Map gehören, zusammenarbeiten, oft aber nicht mit allen MapDrawern einer Unterklasse von Map).

Ich hoffe, ich habe mich halbwegs verständlich ausgedrückt.

Ich bin für jeden Ratschlag dankbar, jede Idee ist mir willkommen!

Vielen Dank schon mal im Voraus, Niko

Soweit, so gut, dies erscheint mir irgendwie recht kompliziert, geht das einfacher?

Jep, ich würde sagen du machst es dir zu kompliziert. Für mich hört sich das dannach an als würdest du jedes bisschen Code in deinem Programm in eine Klasse stecken wollen. Bedenke dabei aber das es Sinn der Klassen ist, das man sie in anderen Programmen wiederverwenden kann. Das scheint mir bei deinen ganzen Klassen nicht der Fall.

Mal ne Frage am Rande: Programmierst du das alles in der Konsole, oder benutzt du die WinApi (oder ähnlich) oder DirectX/OpenGl?

(Warum frage ich: Wenn du mit der WinApi programmierst (wie ich), kann man sich eigentlich das Programmieren mit Klassen auf einen Minmum abgewöhnen, da die WinApi eigentlich für C programmiert ist ...)

Das ist doch nicht dein Ernst .
Die WinApi, die in C geschrieben ist, ist dafür programmiert, dass man sie aus jeder beliebigen Sprache aus nutzen kann.

Ob man "mit Klassen" programmiert, ist eine Stil- und Design-Frage. Mein Tipp: wenn C++, dann auch das Klassenkonzept nutzen und nahe am OOP-Paradigma bleiben.

Bedenke dabei aber das es Sinn der Klassen ist, das man sie in anderen Programmen wiederverwenden kann.

Das stimmt auch nicht immer. Es ist Gang und Gebe, dass man in Programmen hin und wieder Klassen schreibt, die nicht so einfach in einem anderen Programm wiederverwendet werden können. Es geht auch darum, dass man leicht lesbaren (der menschlichen Denkweise nahen) und wartbaren Code schreibt.

Die WinApi, die in C geschrieben ist, ist dafür programmiert, dass man sie aus jeder beliebigen Sprache aus nutzen kann.

Das ist definitiv falsch. Die WinApi funktioniert unter Python/Perl/... nicht, sie muss erst von den Machern der Sprache angepasst werden. Sie funktioniert mit C++, da C++ eine erweiterung zu C ist. Man kann natürlich mit Klassen arbeiten, aber es biettet sich nicht in so vielen Fällen an, als wenn man mit reinem C++ auf der Konsole programmieren würde. Sieh die mal Qt an, das ist eine C++ Api. (Allerdings merkt man die Unterschiede eher bei den chars <-> strings). Bevor du jetzt argumentierst, dass man sowas trozdem machen (mit Klassen unter der WinApi programmieren), möchte ich dich darauf hinweisen, das das meine persönliche Erfahrung ist. Wenn das bei dir anders ist, bitte sehr ... (Ich will hier wirklich keinen Flamewar verursachen)

Ob man "mit Klassen" programmiert, ist eine Stil- und Design-Frage.

Da stimme ich dir zu, aber ich finde es bietet sich bei der WinApi nicht so oft an.

Die WinApi, die in C geschrieben ist, ist dafür programmiert, dass man sie aus jeder beliebigen Sprache aus nutzen kann.

Das ist definitiv falsch. Die WinApi funktioniert unter Python/Perl/... nicht, sie muss erst von den Machern der Sprache angepasst werden. Sie funktioniert mit C++, da C++ eine erweiterung zu C ist. Man kann natürlich mit Klassen arbeiten, aber es biettet sich nicht in so vielen Fällen an, als wenn man mit reinem C++ auf der Konsole programmieren würde. Sieh die mal Qt an, das ist eine C++ Api. (Allerdings merkt man die Unterschiede eher bei den chars <-> strings). Bevor du jetzt argumentierst, dass man sowas trozdem machen (mit Klassen unter der WinApi programmieren), möchte ich dich darauf hinweisen, das das meine persönliche Erfahrung ist. Wenn das bei dir anders ist, bitte sehr ... (Ich will hier wirklich keinen Flamewar verursachen)

Ob man "mit Klassen" programmiert, ist eine Stil- und Design-Frage.

Da stimme ich dir zu, aber ich finde es bietet sich bei der WinApi nicht so oft an.

Deswegen gibts auch kaum irgendwelche FrameWorks die die WinApi kapseln, ausser
vielleicht... MFC, Qt, GTK+, wxWidget,...usw. Das es hier ein eigenes Unter-Forum
für GUI-Toolkits gibt ist wahrscheinlich reiner Zufall.

Bevor du jetzt argumentierst, dass man sowas trozdem machen (mit Klassen unter der WinApi programmieren), möchte ich dich darauf hinweisen, das das meine persönliche Erfahrung ist

Du hast eben nicht viel Erfahrung. Warum nutzt man WinApi in einem C++ Programm: Weil man ein bisschen Oberfläche haben will und das Programm schlank haben will. Und guter Stil ist es dann Oberfläche und Programmlogik getrennt zu halten. Und warum sollte man dann die Programmlogik nicht mit Klassen gestalten? Noch besser wäre die WinApi-Funnktionalität, die man benötigt zu wrappen.

Wenn man sehr viel mit Oberflächen macht würde man so wieso auf eine gute C++ Gui-Bibliothek zurückgreifen.

Bedenke dabei aber das es Sinn der Klassen ist, das man sie in anderen Programmen wiederverwenden kann. Das scheint mir bei deinen ganzen Klassen nicht der Fall.

Äh, sicher? Hast du das irgendwo gelesen oder sprichst du aus Erfahrung?
Weil das nicht zwangsläufig der Fall ist, eher im Gegenteil: zwar sollten die meisten Klassen Klassen wiederverwenden aber die wenigsten Klassen eignen sich zur Wiederverwendung...

flammenvogel schrieb:

(Warum frage ich: Wenn du mit der WinApi programmierst (wie ich), kann man sich eigentlich das Programmieren mit Klassen auf einen Minmum abgewöhnen, da die WinApi eigentlich für C programmiert ist ...)

Könntest du kurz darlegen wie du auf diese Nicht-Folgerung kommst? Dass in C++ geschriebene Programme uU leichter oder mit weniger Aufwand mittels C++ Bibliotheken als mittels C-Bibliotheken zu erstellen sein können heißt noch lange nicht dass selbige Programme besser/schneller/was-auch-immer in C geschrieben werden können...

flammenvogel schrieb:

(Ich will hier wirklich keinen Flamewar verursachen)

Newbie-Bashing ist auch nicht viel toller SCNR

richie schrieb:

Ob man "mit Klassen" programmiert, ist eine Stil- und Design-Frage. Mein Tipp: wenn C++, dann auch das Klassenkonzept nutzen und nahe am OOP-Paradigma bleiben.

Ach ja? Dir ist klar dass C++ eine Multi-Paradigmensprache ist und dass C++ "OOP-Paradigma"-technisch gesehen nicht unbedingt der Stein der Weisen ist?

Ich lerne gerne dazu: kläre mich auf wann man unter C++ auf OOP verzichten sollte?

Ich lerne gerne dazu: kläre mich auf wann man unter C++ auf OOP verzichten sollte?

Würdest du das oben so machen??? Mir ist das zu kompliziert, da schreibe ich lieber für jede Aufgabe eine Funktion, und packe das alles in ein Programm. Obwohl man sicher auch einige Sachen an dem Problem gut mit Klassen lösen könnte, alles ist aus meiner Sicht übertrieben.

Du hast angefangen diesen Thread vom Thema zu entfernen. Du wolltest jemanden, der richtigerweise ein Problem in C++ mit dem Klassenkonzept lösen wollte, mangels Wissen, schlechten Programmier-Stil einreden. Das gehört sich nicht in einem C++ Unterforum.

Du beweisst, dass du C++ und OOP nicht beherrschst. Deswegen meidest du es. Selbstverständlich ist die WinAPI eine in C geschriebene API. Sonst wäre es nicht so einfach möglich sie aus anderen Sprachen zu nutzen (beispielsweise Delphi, Pascal, Assembler ...). Ich sage nicht, dass Perl und Python WinAPI unterstützen. Ich sage nur, dass es problemlos möglich wäre.

Und was meinst du was QT macht? Das was du nicht hinkriegst. Die Windows-API mit C++ wrappen.

Ebenfalls sagte ich dass es guter Stil ist, Programmlogik und Oberfläche zu trennen. Wenn man es schon nicht hinkriegst die WinAPI zu wrappen, dann kann man oder sollte man die Programmlogik in einem C++ entsprechenden Stil lösen, wenn man C++ nutzen will.

Programmierst du eine Lib für das Spiel die du wiederverwenden möchtest (bis zu einem gewissen Grade eine gute Idee) oder betreibst du komplexe Generalisierung "für den Fall dass, irgendwann, irgendwie, vielleicht" könnte ich das alles ja mal brauchen?

In Sachen Komplexität sind die paar Klassen denke ich nicht allzu schwerwiegend, was mich persönlich allerdings 'stört':

Wenn du (s.o.) kein Lib baust und deine MapLayer keine Abhängigkeiten untereinander haben, brauchst du wirklich eine LayeredMap? Reicht ein 'layered maps' nicht aus?
Wozu brauchst du überhaupt verschiedene Arten von Maps - geht es nur um das "könnte, eventuell"?
Vielleicht wäre es insgesamt nicht schlecht wenn du diesen Gedanken von 'essentiell verschiedenen' ein wenig erläutern könntest!? Welche Arten von Maps neben LayeredMap schweben dir vor, warum können es nicht schlicht verschiedene Tiles(?)/Objekte auf der Map sein?

Was mir allerdings als erstes aufgefallen ist ist dein MapObject, welches du in den Vordergrund rücken zu scheinst.
Ist es nicht eher so dass das Map-Object das Hauptsächliche ist? Dass eine Map, wie du selbst sagst, verschiedene MapObjects haben kann aber nicht umgekehrt? Dass das MapObject eher MapPresentation o.ä.(tm) heißen sollte ("FooObject" ist allerhöchstens für Variablen nicht nichtssagend..)?

Was deine Konsistenzprobleme angeht: wenn es bei der Zusammenstellung um mehr geht als von einem Level/Map-File zu laden solltest du dich evtl. etwas ausführlicher zu deinem Vorhaben äußern...

richie schrieb:

@finix:
Ich lerne gerne dazu: kläre mich auf wann man unter C++ auf OOP verzichten sollte?

Danke!

@finix:

Ich lerne gerne dazu: kläre mich auf wann man unter C++ auf OOP verzichten sollte?

Hehe.. sorry.. wollte damit nicht ausdrücken dass du auf OOP verzichten sollst
Nur dass, wie gesagt, C++ nicht das Musterbeispiel bezüglich OOP darstellt und nicht zwangsläufig auf OOP beschränkt ist...
Lies den Post nochmal.

edit: nochmal, ich programmiere selbst Objektorientiert, widerspreche flammenvogel absolut, aber C++ ist eine Multiparadigmensprache.
Aber dogmatisch OOP muss auch nicht sein.

Die Standard-Bibliothek ist auch ein gutes Beispiel, dass OOP eher in einem geringen Maße genutzt wird (Kaum Vereerbung).

Obwohl ich Generics manchmal doch schon sehr vermisse finde ich "die STL" (die du wahrscheinlich meinst) nicht schlecht. Nicht alles muss ein AlgorithmObject o.ä. sein. Nicht alles muss ein Objekt sein. Freie Funktionen sind toll. Und auch Objekte müssen nicht zwangsläufig in einer gigantischen Vererbungshierarchie stecken...

richie schrieb:

Aber dennoch ist sie bis zu einem gewissen Grad OO. Meine Aussage, die du zitierst hast, ist demgegenüber kein Widerspruch.

Wollte ich damit auch nicht ausdrücken. Hatte sich aber angehört wie C++ -> OOP, zwangsläufig

richie schrieb:

Ausserdem betrachte ich OOP nicht unbedingt als ein Sprachenfeature. Hin und wieder muss auch mal plain C benutzen und auch da versuche ich das Problem OO zu lösen.

Wollte ich damit ebenfalls nicht ausdrücken. OOP wird eben mehr oder weniger von einer Sprache unterstützt oder nicht - aber du musst zugeben dass "selbst C++" nicht wirklich der Gral der OOP ist, oder!?