Konzept 1:

class EventManager {
    // Diese Liste speichert alle Objekte, die auf Events reagieren wollen
    list<Callback*> cbs;
    // sendet das Event an jedes Objekt in der Callbackliste
    void handleEvents();
};
class Callback {
    // Diese Methode wird vom EventManager aufgerufen
    virtual bool onMouseButtonDown(int x, int y) = 0;
};
// eine konkrete Implementation des Interfaces
class ButtonCallback : public Callback {
    bool onMouseButtonDown(int x, int y) { /* führe aktion aus */ }
};

Ich schätze mal das ist die "klassische" objektorientierte Umsetzung, oder? (Das Observer-Pattern ist ja noch erkennbar)

Konzept 2:

// Die Signatur einer Callbackfunktion für Mausklicks
typedef boost::function<bool (int, int)> callback;
class EventManager {
    // Diese Liste speichert alle Funktionen, die auf Events reagieren
    std::list<callback*> cbs;
    // ruft alle Funktionen in der Liste auf
    void handleEvents()
};
// freie Funktion
bool onMouseButtonDown(int x, int y) { /* führe Aktion aus */ }
class Button {
    // Memberfunktion
    bool onMouseButtonDown(int x, int y) { /* führe Aktion aus */ }
    // Funktor
    bool operator() (int x, int y) { /* führe Aktion aus */ }
};
// freie Funktion
callback a(onMouseButtonDown);
// Memberfunktion
Button button;
callback b(boost::bind(&Button::onMouseButtonDown, &button, _1, _2));
// Funktor
callback c(button);
}

Das ist dann die etwas "andere" Umsetzung. Was meint ihr, taugt sie was oder bin ich blind und sehe ihren großen Nachteil nicht?

Konzept 3 wäre die Verwendung von boost::signal oder libsigc++, aber so großes Kaliber brauch ich für mein kleines Spiel eigentlich gar nicht.

Vielen Dank im voraus

Objekte, die auf Mausklicks reagieren sind die Buttons im Menü und die Tiles in der Karte. Muss ich mir jetzt für jeden Button eine Klasse schreiben, die von Callback erbt? Wie regel ich die Beziehung zwischen Button und ButtonCallback? Der Button "hat-ein" ButtonCallback und der ButtonCallback "kennt-seinen" Button. Diese Doppelbeziehung könnte man vermeiden, indem man ButtonCallback weglässt und direkt Button von Callback erben lässt. Jeder Button erfüllt aber eine andere Funktionalität, also müsste man für jeden Button eine Klasse von Button ableiten. Und da ist noch die Frage ist ein Button überhaupt ein Callback?

Dazu kommt, dass der Eventmanager den Mausklick immer an alle Tiles senden würde, aber da die Karte scrollbar ist, kommen ja gar nicht alle in Frage. Es wäre doch viel besser wenn die Karte auf den Mausklick reagiert, dann berechnet auf welches Tile geklickt wurde und von diesem Tile die onMouseButtonDown-Methode aufruft. Gleiches ließe sich auch auf das Menü übertragen, das das Event nur an die gerade sichtbaren Buttons weiterleitet.

Da stellt sich irgendwann die Frage ob man überhaupt Callbacks benötigt. Ich meine für die Mausklicks eigentlich nicht. Für die Mausbewegungen auch nicht, da nur die Karte Mausbewegungen verarbeitet (zum scrollen). Aber irgendwann würde man vielleicht mal gern Abkürzungstasten einbauen und an diesem Punkt ist die Zahl der Objekte, die auf Tastendrücke reagiert unbestimmt, das kann die Eventmanager-Klasse nicht wissen. Spätestens hier wäre es angebracht in einer map/multimap zu jeder Taste eine Callbackfunktion zu speichern. Also wenn man es irgendwann doch braucht, warum dann nicht gleich von Anfang an verwenden?

Angesichts des "für jede Funktionalität eine Klasse von Callback erben lassen"-Problems bin ich dann auf die boost::function-Lösung gekommen. Ich kann mir für eine bestimmte Funktion immer noch eine eigene Klasse schreiben oder einfach nur eine freie Funktion oder eine bestehende Methode einer Klasse als Methodenzeiger übergeben. Und ich benötige auch nur eine Buttonklasse, die einfach eine boost::function speichert. Dann schreibe ich Funktionen/Funktoren für jede gewünschte Aktion und erstelle einen Button, dem ich die Funktion übergebe. Oder gibt es hier auch eine ganz simple Lösung mit Vererbung und Polymorphie?

Es tut mir leid dass der Text so lang geworden ist, aber ich finde solche Designentscheidungen sind extrem wichtig und sollten nur mit reiflicher Überlegung getroffen werden. Also wo liege ich mit meinen Einschätzungen falsch, wo habe ich den einfachen, schnellen Weg übersehen, mache ich mir einfach alles zu kompliziert?

btw Frohe Weihnachten noch

kurz gesagt: viele kleine light weight observer, anstatt eines einzigen riesigen event managers, der sonst mit events nur so überschüttet wird.

Die Klasse map erfährt also von einem Mausklick, sie überprüft ob auf die map geklickt wurde, sie berechnet das Tile auf das geklickt wurde und ruft die passende Methode des Tiles auf. Handelt es sich um ein leeres Tile veranlasst das Tile das Menü dazu die richtigen labels und buttons anzuzeigen. Klickt man dann z.B. auf Haus bauen, so soll auf dem aktiven Tile das Haus errichtet werden. Handelt es sich um ein bebautes Tile soll das Menü entsprechend die Informationen und Funktionen dieses Gebäudes anzeigen.

Ich wollte diesen Bereich vorerst einfach so simpel wie möglich halten und für diesen Punkt spielt es auch gar keine so große Rolle wie die Callbacks realisiert sind oder ob überhaupt Callbacks verwendet werden.

Wie würdest du denn die Sache mit den Buttons angehen? Vorallem dass ich nicht für jeden individuellen Button eine extra Klasse von Button/von einem bestimmten Interface ableiten muss. Oder ist das gar nicht so schlimm und völlig normal?