War vielleicht ein Missverständnis: Die Buttons sind nicht spezialisiert, sondern die Aktivitäten, welche durch sie ausgelöst werden (hat mit "Quelle des Ereignisses" zu tun - beschreib ich ein bisschen weiter unten; hab aber schon einen ersten Schritt in die Gegenrichtung gemacht - s. ebenfalls unten).
Ja, das mit dem Overhead und dem Klassenzoo ist der Punkt, der mich zu stören beginnt. Aktuell habe ich mal in einem ersten Schritt zusammen gefasst, dass es "nur" noch eine Klasse für Button-Aktivitäten gibt, dafür dann pro Button eine eigene Instanz, die im Konstruktor den Typ mit bekommt (also z.B. Gebäude, Angriff usw.).
Bei mir sind im Gegensatz zu z.B. Java die Methoden, die ich bei Eintreten von Ereignissen rufe parameterlos (Java hat in den Versionenm die ich von früher kenne Event-Objekte mitgegeben, aus denen man die Quelle des Ereignisses entnehmen konnte. Dann musste aber auch oft mit instanceof und casts gearbeitet werden). Dadurch muss die Info, woher das Ereignis kommt entweder eindeutig sein, oder anders ermittelt werden.
Wo ggf. der Klassenzoo noch etwas groß ist ist bei der Ereignisverarbeitung im Fenster. Dort habe ich ähnlich wie bei Java für verschiedene Ereignisarten unterschiedliche verarbeitende Klassen implementiert (z.B. für Mausereignisse, Button-Ereignisse usw.). Die unterscheiden sich aber aktuell kaum in den Schnittstellen (aber in der Tätigkeit). Die Klassen tun kaum was - d.h., ich könnte deren Logik auch direkt in der Fensterklasse implementieren. Dann würde diese aber wieder recht aufgebläht ... (wie man's macht ...
)
Callbacks kann ich mir nochmal anschauen, bin ich bisher noch kein so Fan von ...