ich stecke in einem Designproblem und wollte fragen, wie ihr das lösen würdet.

bisher:

class ITexture
{

};

class D3D9Texture : public ITexture
{

};

class IRenderer
{
public:
	virtual void RenderTexture(shared_ptr<ITexture> texture);
};

class D3D9Renderer : public IRenderer
{
public:
	virtual void RenderTexture(shared_ptr<ITexture> texture)
	{
		shared_ptr<D3D9Texture> temp = static_pointer_cast<D3D9Texture>(texture);

		//zeichne temp
	}
};

jetzt brauchte ich aber die Möglichkeit eine animierte Textur zu zeichnen. Da ich diese bisher nur an einer Stelle brauchte, hatte ich die Funktionalität nur dort eingebaut, generell möchte ich das ganze aber auch in einer Klasse kapseln, um sie auch an anderen Stellen benutzen zu können.

Vorgestellt hab ich mir die Klasse bisher so:

class AnimatedTexture
{
public:
	void AddFrame(shared_ptr<ITexture> frame)
	{
		frames.push_back(frame);
	}

private:
	vector<shared_ptr<ITexture> > frames;
	int nextFrame;
	TimeSpan interval;
};

Doch wie integriere ich das ganze nun in mein bestehendes System? Ich möchte zB einer PictureBox ein Textur Objekt zuweisen können, bei dem es egal ist, ob es animiert ist oder nicht und quasi erst beim Zeichnen wird entschieden, was dort eigentlich gezeichnet werden soll.

Möglichkeit 1:
Ich ersetze alle Vorkommen von ITexture durch AnimatedTextur. Alle statischen Texturen sind dann eine AnimatedTextur mit nur einem Frame. (gefällt mir nicht)

Möglichkeit 2:
AnimatedTexture erbt von ITextur (gefällt mir auch nicht, weil AnimatedTexture keine ITexture ist). Würde zur Folge haben, dass ich an den Stellen wo sie eingesetzt wird, entscheiden müsste, was ich denn grad vor mir hab (normal oder animiert).

Möglichkeit 3:
AnimatedTexture und ITexture erben von zB IDrawable. IDrawable bietet eine Methode Get an:

class IDrawable
{
public:
	virtual IDrawable Get() = 0;
};

class ITexture : public IDrawable
{
public:
	virtual IDrawable Get()
	{
		return *this;
	}
};

class AnimatedTexture : public IDrawable
{
public:
	virtual IDrawable Get()
	{
		//falls interval abgelaufen ++currentFrame
		return frames[currentFrame];
	}
};

class D3D9Renderer : public IRenderer
{
public:
	virtual void RenderTexture(shared_ptr<IDrawable> texture)
	{
		shared_ptr<D3D9Texture> temp = static_pointer_cast<D3D9Texture>(texture.Get());

		//zeichne temp
	}
};

Gefällt mir aber auch nicht wirklich, weil außer in der Renderer Klasse trotzdem noch überprüft werden muss, was für ein IDrawable ich benutzen will...

Hat jemand eine Idee, wie ich das Problem möglichst gut (besser wie meine Vorschläge) lösen könnte?

greetz KN4CK3R

AnimatedTexture erbt von ITextur (gefällt mir auch nicht, weil AnimatedTexture keine ITexture ist).

Warum denn nicht? Also wahrscheinlich erklärt sich die Frage, wenn man wüsste was denn bei dir eine ITextur ist. Wir sehen nur ein nichts

class ITexture
{

};

Nach dieser Definition würde ich sagen, dass alles ein ITexture ist. Aber irgendeine Schnittstelle wird ITexture ja deklarieren. Ich hätte halt vermutet, dass es irgendeine Schnittstelle gibt, mit der man die konkrete Textur halt rendern kann. Und kann eine animierte Texture nicht einfach den aktuellen Frame rendern?

Im übrigen hängst Du immer noch an deinem hier schon ausgiebig kritisierten Design

virtual void RenderTexture(shared_ptr<IDrawable> texture)
    {
        shared_ptr<D3D9Texture> temp = static_pointer_cast<D3D9Texture>(texture.Get());

Ich fürchte, dass der Thread wieder in diese Richtung abgleiten wird...

Im übrigen hängst Du immer noch an deinem hier schon ausgiebig kritisierten Design
Ich fürchte, dass der Thread wieder in diese Richtung abgleiten wird...

Hm jetzt weiß ich gar nicht, ob Du das überhaupt warst. Kam mir nur sehr bekannt vor:
http://www.c-plusplus.net/forum/288208

Beide ein Freund von Übergeneralisierung.
Wenn eine animierte Textur tatsächlich keine Textur ist, dann geht es eben Richtung 4.Möglichkeit von Tachyon. Oder, wenn sie ein gemeinsames Konzept haben, haben sie vielelicht eine gemeinsame Basisklasse wie deine Möglichkeit 3, wobei mir dieses Get auch überhaupt nciht gut gefällt. Mir ist aber halt noch nicht klar, wieso eine anmierte Textur keine Textur ist. Die Anwort auf Deine Frage, liegt eben in den Details, die wir hier nicht haben.

@Tachyon: Ich möchte zB aber bei einer PictureBox im Gui einfach der Image Eigenschaft eins von beidem zuweisen. Bisher ist dort Image als shared_ptr<ITexture> implementiert. Ich möchte aber sowas machen können:
[cpp]pictureBox->Image = statische Texture oder animierte Textur[/cpp]

@dot: Je nach verwendeter Technik gibt es natürlich noch OpenGLTexture, D3D10Texture etc und jede Technik hat ihren eigenen Renderer. Der OpenGLRenderer castet ITexture nach OpenGLTexture etc. Intern wird alles einheitlich über das IRenderer Interface behandelt, weil dort noch nicht klar ist, welche Technik der Benutzer letztendlich einsetzt.

greetz KN4CK3R

struct abstract_render_engine
{
    virtual void render(d3d9_texture texture) = 0;
    virtual void render(d3d9_animated_texture texture) = 0;

    virtual void render(ogl_texture texture) = 0;
    virtual ~abstract_render_engine();
};

struct abstract_texture
{
    virtual void render(abstract_render_engine engine) = 0;
    virtual ~abstract_texture();
};

class d3d9_texture : public abstract_texture
{
    render(abstract_render_engine engine){ engine.render(*this); }
};

class d3d9_animated_texture : public abstract_texture
{
    render(abstract_render_engine engine){ engine.render(*this); }
};

class d3d9_renderer : public abstract_render_engine
{
    virtual void render(d3d9_texture texture)
    {
        //do things with texture
    }

    virtual void render(d3d9_animated_texture texture)
    {
        //do things with animated texture
    }

    virtual void render(ogl_texture texture)
    {
        throw texture_not_supported();
    }
};

? Irgendwie so.

Mit einer abstrakten Fabrik könntest Du dann noch gewährleisten, dass man zu einem Renderer nur die passenden Texturen etc. erzeugt werden können.

@Tachyon: Ich möchte zB aber bei einer PictureBox im Gui einfach der Image Eigenschaft eins von beidem zuweisen. Bisher ist dort Image als shared_ptr<ITexture> implementiert. Ich möchte aber sowas machen können:

Dann muss Image eben beide Typen annehmen (Überladung). Wenn Du Sachen nicht einheitlich behandeln kannst, dann musst Du irgendwo separate Behandlungen dafür bereitstellen. Das kannst Du entweder suaber von Anfang an machen oder irgendwo in den Eingeweiden mit Hacks wie dynamic_Cast, die hier aber eigentlich überflüssig wären.

@Tachyon: ist das nicht meine Möglichkeit 3 mehr oder weniger?

Ich habe mich vom Design her an dem .NET Framework orientiert. Dort hat eine PictureBox die Eigenschaft Image, die sowohl normale Grafiken als auch animierte verwalten kann. Wie genau die Klasse (System.Drawing.Image) das handhabt, weiß ich nicht, dazu schaue ich mir eventuell deren Quellcode später einmal an. Ich nehme an so wie bei mir in Möglichkeit 1.

greetz KN4CK3R

Insgesamt läuft es also auf eine Basisklasse hinaus, von der beide Versionen erben, was aber irgendwie wieder auf das Get in Möglichkeit 3 hinausläuft, wenn ich meiner AnimatedTexture nicht die Möglichkeit gebe, sich wie eine ITexture zu verhalten (Fill-Methoden, etc) Damit könnte ich ja sogar noch leben, indem sie zB eine Methode SelectFrame(frameNum) bekommt und dann die Methoden nur auf dieses eine Frame ausführt. :|

greetz KN4CK3R

@Tachyon: ist das nicht meine Möglichkeit 3 mehr oder weniger?

Eher weniger.

Ist ein ITexture Interface, dass Methoden zum Bearbeiten von Bitmapdaten anbietet kein vernünftige Abstraktion?

Die Tatsache dass du diesen Downcast in RenderTexture brauchst, schreit doch nach Designfehler.

Was genau ist es, das deine Anwendung tut und warum muss es dabei unbedingt Renderer->RenderTexture() sein und nicht z.B. Texture->Render() ?

class D3D9Renderer : public IRenderer
{
public:
	virtual void RenderTexture(shared_ptr<ITexture> texture)
	{
		shared_ptr<D3D9Texture> temp = static_pointer_cast<D3D9Texture>(texture);

		device->SetTexture(0, temp->GetTexture());

		//ob ich hier jetzt in D3D9Texture oder einen Schritt später GetTexture() in LPDIRECT3DTEXTURE9 caste, ist ja egal...

		AddVertex(x, y, 0.0f, 0.0f);
		AddVertex(x + w, y, 1.0f, 0.0f);
		AddVertex(x, y + h, 0.0f, 1.0f);
		AddVertex(x + w, y, 1.0f, 0.0f);
		AddVertex(x + w, y + h, 1.0f, 1.0f);
		AddVertex(x, y + h, 0.0f, 1.0f);

		device->DrawPrimitiveUP(D3DPT_TRIANGLELIST, verticesNum / 3, &vertices[0], sizeof(Vertex2D));
	}
};

Die ganze Vertex Verwaltung hat in der Textur nichts zu suchen. IDirect3DDevice9 rendert ja die Textur und nicht umgekehrt. Aus diesem Grund gibt es auch keine Textur->Render() Funktion (klar, sorum wäre das ganze absolut unproblematisch)

greetz KN4CK3R

virtual void render(d3d9_texture texture)
    {
        device->SetTexture(0, texture->GetTexture()); //kein cast
        AddVertex(x, y, 0.0f, 0.0f);
        AddVertex(x + w, y, 1.0f, 0.0f);
        AddVertex(x, y + h, 0.0f, 1.0f);
        AddVertex(x + w, y, 1.0f, 0.0f);
        AddVertex(x + w, y + h, 1.0f, 1.0f);
        AddVertex(x, y + h, 0.0f, 1.0f);

        device->DrawPrimitiveUP(D3DPT_TRIANGLELIST, verticesNum / 3, &vertices[0], sizeof(Vertex2D));         
    }

greetz KN4CK3R

den cast für eine Renderer Klasse einzusparen, die für jeden beliebigen Texturtyp eine RenderMethode bereitstellt, halte ich für etwas fragwürdig. Wenn eine neue Grafik-API dazukommt, muss jeder Renderer (oder nur der BaseRenderer, falls er nicht mehr virtuel gemacht wird) geändert werden, nur um in der Funktionen eine "gibts net" Exception zu werfen. Das kann unmöglich ein gutes Design sein.

greetz KN4CK3R

Doch ist es. Denn jeder neue Renderer und die dazu gehörenden Texuren ist unterschiedlich, und das wird dadruch ausgedrückt. Du hingegen versuchst die ganze Zeit, Unterscheide auf "Teufel komm raus" gleich zu biegen. Und das ist scheiss Design. Zu mal die Anzahl der möglichen Renderer vermutlich eher begrenzt sein wird.

Ein Autohändler stellt ja auch nur ein Schild "kaufe Kraftfahrzeuge" und nicht "kaufe PKWs", "kaufe Motorräder", "kaufe LKWs" vor sein Geschäft und sagt dem LKW Fahrer dann "ich kaufe ihren LKW aber nicht ihren PKW und auch nicht ihr Motorrad" eben weil der LKW Fahrer nur einen LKW hat.

greetz KN4CK3R

den Downcast brauche ich, damit ich an das eigentliche LPDIRECT3DTEXTURE9 Objekt (in D3D9Texture) komme, das mir das IDirect3DDevice9 (in D3D9Renderer) dann zeichnet.

Mir ist klar warum du den Cast brauchst. Das Problem liegt ja eben genau in der Natur dieses Designs, das den Cast erst notwendig macht. Der Cast ist nur Symptom. Worum es geht ist, mal festzustellen, dass hier ein Designfehler vorliegt.

KN4CK3R schrieb:

Die ganze Vertex Verwaltung hat in der Textur nichts zu suchen. IDirect3DDevice9 rendert ja die Textur und nicht umgekehrt. Aus diesem Grund gibt es auch keine Textur->Render() Funktion (klar, sorum wäre das ganze absolut unproblematisch)

Und was interessiert das die Anwendung, dass es intern ein ID3Direct3DDevice9 gibt, das die Textur rendert? Warum muss deine Abstraktionsschicht unbedingt das Interface der zugrundeliegenden Grafik-API widerspiegeln? In D3D11 hast du plötzlich keinen Device mehr, der rendert, sondern einen DeviceContext. Deine D3D11 Implementierung möchte vielleicht multithreaded Rendering einsetzen. Wie löst du das? Ich vermute mal, deine Anwendung will einfach nur 2D Bildchen malen!? Dann bau ein Interface, dass es erlaubt, 2D Bildchen zu malen. Und zwar so wie die Anwendung es will und nicht so wie die Grafik-API es will.

greetz KN4CK3R

Eine Textur beinhaltet nur ein Bild (außer die animierte ;)) und dadran wird sich auch nichts ändern. Dass alles auf einer Textur ist und nur gezeichnete Ausschnitt verschoben wird, ist nicht geplant und auch nicht gewollt.

greetz KN4CK3R

Ein Autohändler stellt ja auch nur ein Schild "kaufe Kraftfahrzeuge" und nicht "kaufe PKWs", "kaufe Motorräder", "kaufe LKWs" vor sein Geschäft und sagt dem LKW Fahrer dann "ich kaufe ihren LKW aber nicht ihren PKW und auch nicht ihr Motorrad" eben weil der LKW Fahrer nur einen LKW hat.

Ein PKW Händler stellt aber das Schild auf "Kaufe PKW" und ein LKW Händler stellt das Schild auf "Kaufe LKW". Denn ein PKW Händler will nur PKW haben und ein LKW Händler nur LKW. Ein Kraftfahrzeugshandel ist ein abstraktes Gebilde, genau wie ein Kraftfahrzeug. Wenn es kein generelles Konzept gibt, dass jeder Kraftfahrzeughandel ein beliebiges Kraftfahrzeug kaufen kann, dann gibt es kein Schild "Kaufe Kraftfahrzeug", dass vor jedem Kraftfahrzeughandel steht.

Es ist das gleiche wie hier, eine Verletzung des LSP. Das Schild "Kaufe Kraftfahrzeuge" ist für den PKW Handel mit einer zusätzlichen Bedingung versehen, der PKW Händler sagt "Ätsch.. kaufe gar nicht alle Kraftfahrzeuge, ich kaufe nur PKW". Du kannst dem PKW Händler nicht einfach statt einem PKW ein Motorrad verkaufen (Substitution), da wird es irgendwo Ärger geben.