ChaosAngel
18.01.2003, 11:14
Also :D
Hier wird nun der Aufbau des Frameworks besprochen. Wie also alle Klassen zusammenarbeiten und welche Schnittstellen dem Clienten zur Verfügung stehen und wie er die Engine konfigurieren und erweitern kann.
Der Aufbau mit Policies ist schon besprochen.
Die Client legt eine Reihe von templateParametern beim instanziieren der Engine fest die diese näher beschreiben.
Jedes Objekt der Engine das Interface-Charakter hat leitet von einer gemeinsamen template-base Klasse ab. Im folgenden BaseInterface genannt. Darunter zählen unter anderem alle Klassen, die auf andere Objekte der Engine zugreifen müssen.
(SceneManager auf den Renderer, etc... Sound, Input, Netzwerk, etc...)
Die Basisklasse all dieser Interfaces erhält einen Pointer auf die Engine ! Damit hat jedes Interface zugriff auf die anderen Interfaces (insofern sie integriert sind)
Falls ein Interface auf ein nicht implementiertes Interface zugreifen will kommt ein CompileTime Error.
Das ganze würde ungefähr so aussehen:
template<class T>
class BaseInterface
{
public:
BaseInterface(T* enginePointer);
private:
T* EnginePointer;
};
//Beispielklasse
template<class T>
class Sound : public BaseInterface<T>
{
private:
T::ThreadingType::SmartPointer bla;
};
template<class Threading = Singlethread,
template<class> typelist_der_ApiRenderer = TypeList2<OGLRenderer,D3DRenderer>,
class Sound = DXSound,
class Input = DXInput,
class Network = NoNetwork
>
class Engine
{
public:
typedef Engine<Threading,typelist_der_ApiRenderer,Sound,Input,Net work> EngineType;
typedef Threading ThreadingType;
private:
Renderer<typelist_der_ApiRenderer>* Renderer_;
Sound* Sound_;
};
Engine::Engine()
{
Renderer_ = new Renderer<typelist_der_ApiRenderer>(this);
Sound_ = new Sound(this);
}
So hat jedes Interface nicht nur Zugriff auf die Engine und damit auch die anderen Interfaces, sondern auch den Typen der Engine und damit zum Beispiel auf den ThreadingType, der einen SmartPointer definieren könnte, der entweder MultiThread-sicher ist oder nicht. So würden alle Klassen des Frameworks den selben Typ von SmartPointer verwenden, entweder einen sicheren oder einen nicht sicheren. Je nachdem in welcher Umgebung die Engine erstellt wird.
(Beispiel bla in Sound)
grafische smilies deaktiviert wg source-code - mfg tipo
Hier wird nun der Aufbau des Frameworks besprochen. Wie also alle Klassen zusammenarbeiten und welche Schnittstellen dem Clienten zur Verfügung stehen und wie er die Engine konfigurieren und erweitern kann.
Der Aufbau mit Policies ist schon besprochen.
Die Client legt eine Reihe von templateParametern beim instanziieren der Engine fest die diese näher beschreiben.
Jedes Objekt der Engine das Interface-Charakter hat leitet von einer gemeinsamen template-base Klasse ab. Im folgenden BaseInterface genannt. Darunter zählen unter anderem alle Klassen, die auf andere Objekte der Engine zugreifen müssen.
(SceneManager auf den Renderer, etc... Sound, Input, Netzwerk, etc...)
Die Basisklasse all dieser Interfaces erhält einen Pointer auf die Engine ! Damit hat jedes Interface zugriff auf die anderen Interfaces (insofern sie integriert sind)
Falls ein Interface auf ein nicht implementiertes Interface zugreifen will kommt ein CompileTime Error.
Das ganze würde ungefähr so aussehen:
template<class T>
class BaseInterface
{
public:
BaseInterface(T* enginePointer);
private:
T* EnginePointer;
};
//Beispielklasse
template<class T>
class Sound : public BaseInterface<T>
{
private:
T::ThreadingType::SmartPointer bla;
};
template<class Threading = Singlethread,
template<class> typelist_der_ApiRenderer = TypeList2<OGLRenderer,D3DRenderer>,
class Sound = DXSound,
class Input = DXInput,
class Network = NoNetwork
>
class Engine
{
public:
typedef Engine<Threading,typelist_der_ApiRenderer,Sound,Input,Net work> EngineType;
typedef Threading ThreadingType;
private:
Renderer<typelist_der_ApiRenderer>* Renderer_;
Sound* Sound_;
};
Engine::Engine()
{
Renderer_ = new Renderer<typelist_der_ApiRenderer>(this);
Sound_ = new Sound(this);
}
So hat jedes Interface nicht nur Zugriff auf die Engine und damit auch die anderen Interfaces, sondern auch den Typen der Engine und damit zum Beispiel auf den ThreadingType, der einen SmartPointer definieren könnte, der entweder MultiThread-sicher ist oder nicht. So würden alle Klassen des Frameworks den selben Typ von SmartPointer verwenden, entweder einen sicheren oder einen nicht sicheren. Je nachdem in welcher Umgebung die Engine erstellt wird.
(Beispiel bla in Sound)
grafische smilies deaktiviert wg source-code - mfg tipo