# [Klassendesgin] Verhalten von Subklassen für Aufgabenteilung benutzen.



## Volvagia (22. Nov 2012)

Blöder Titel, aber mir viel kein besserer ein.
Ich habe in Gedanken ein Spiel "entwickelt". Objektsteuerung sollte darin per Skript möglich sein. Dazu habe ich mir das als XML so gedacht:

[XML]
<xml-Anfangstag/> <?-- Den merke ich mir nie -->
<parent-tag>
	<object name="A"... >
		<event trigger="0">
			<event_condition (irgendwelche parameter)/>
			<event_task name="show text" parameter="Text">
			<event_task name="wait" parameter="100">
			<event_task name="show text" parameter="Anderer Text">
		</event>
	</object>
</parent-tag>
[/XML]

Mal ganz grob. ^^

Dabei dachte ich, dass sich die Conditions (also Bedingungen zum Auslösen) bei einen Manager registrieren könnten, der sie über Änderungen, die sie interessieren könnten informiert. Die Tasks könnten per Name zu Klassen die ein gemeinsames Interface implementieren zugeordnet werden.

Nur mir fällt nicht ein, wie ich Dinge wie "show text" nun im Endeffekt realisierbar wären.

Ich hatte als einzige Idee die Möglichkeit, allen Tasks ein Schnittstelle mitzugeben, das auch die Dinge kennt, die dafür benötigt werden. Die Idee fand ich aber nicht so gut, da dann die Schnittstelle statt den Event-Tasks die Änderungen vornimmt, wodurch fast alles in der Schnittstelle als Controller liegt und die eigendlichen Task oft nicht mehr machen als eventuelle Parameter zu parsen und die jeweilige Methode aufzurufen.
Alles an eine Klasse weiterdelegieren kommt mir sehr grob vor.


----------



## nillehammer (22. Nov 2012)

Volvagia hat gesagt.:
			
		

> Dabei dachte ich, dass sich die Conditions (also Bedingungen zum Auslösen) bei einen Manager registrieren könnten, der sie über Änderungen, die sie interessieren könnten informiert. Die Tasks könnten per Name zu Klassen die ein gemeinsames Interface implementieren zugeordnet werden.


Das klingt für mich ganz klar nach Observer-Pattern. Hattest Du evtl. auch schon im Sinn?
Du Definierst ein Event-Objekt. Das kann ja so ziemlich alles enthalten, was für das Eventhandling gebraucht wird. Die Condition implementiert ein Interface und hat einen eventHandler, in dem sie das Event-Objekt übergeben bekommt, das sie zur Prüfung oder was auch immer benötigt. Das ist der öffentliche Teil. intern kann die Condition ja so ziemlich alles machen.


----------



## Volvagia (23. Nov 2012)

Danke, daran dachte ich auch schon.

Es ging mir mehr um die Events. In dem Beispiel könnte der Text noch gelöst werden, indem die Events mitgerendert wird und ihn einfach drauf zeichnet.
Falls aber gröberes passieren soll, z. B. sich bei einen typischen SNES-Like-RPG sich eine Person (GameObject) wo anderst hinbewegen soll sobald das Event durch anreden getriggert wird, bräuchte es mehr Zugriff, befindet sich durch mein Model aber am Ende des Klassenbaums.

Ich hab mal ein kleines UML gebastelt, wie ich mir das in etwa vorstelle.


----------

