Skip to main content
gamedev.net
🔒 Locked

Virtual classes with different behavior

Started by rcpedersen Aug 24, 2006 at 7:30 AM 6 replies 1.1k views
Original Post
rcpedersen
rcpedersen
I have a design dillema which I hope you can assist me with. The challenge is that I have two dynamic geomtries which are updated/changed at different events and also they require different data in order to perform the desired change. For simplicity I would like the general render pipeline to be as clean as possible so that the pipeline can delegate the actual update to the specific object/class. The not so pretty implementation would be an abstract class which delegates the operations, however since the geometries are very unrelated different information is needed, I have tried to list the problem below. There most be a much cleaner way of implementing this. The problem is that some kind of description is needed the way I have implemented it right now but this results in some nasty coupling and also reductant data. class CDGDescriptor{ flags, with typeinfo?? and update data }; class CDynamicGeometry { private: public: virtual void Update(CDGDescriptor& descriptor) //! needed for externall rendering virtual DWORD GetFVF() = 0; virtual IDirect3DVertexBuffer9* GetVertexBuffer() = 0; virtual UINT GetPrimitiveCount() = 0; }
DesignerX
DesignerX
Can you please specify what kind of data is needed for the update of the two dynamic geometries ?
and also the two classes which inherit CDynamicGeometry ?


There is nothing that can't be solved. Just people that can't solve it. :)
rcpedersen
rcpedersen
NON HETEROGENOUES:

As mentioned the geometries are very unrelated different information is needed.
Lets say I have a dynamic geometry which is a view aligned stack of slices and another geometry which is a polygonization of an implicit surface.

One geometry is basicly a 3D mesh which requires ordinary surface shading during rendering and for updates requires a iso surface value, the other(slice stack) requires a couple of matrices inorder to be reconstructed correctly, in total the one requires information which the other doesnt.

GoF strategy pattern:
The pattern indicated by my code is the GoF strategy pattern the dilema is that state information is supplied to the child classes even though they are in no need of it.
indieboy
indieboy
i suppose you could create a interface, say, Renderable, and make theses two geometries implement it.

this way you can always render Renderable objects.
leandro.
rcpedersen
rcpedersen
ehmmm... sure ;-)

The strategy (GoF) is exactly an interface "like" pattern, besides that is not the dillema...

jpetrie
jpetrie
Then what is the dilemma? Without further explanation, I am left with the impression that you want to do two completely different actions (both of which can be called "updates") on two completely unrelated types, but in a "generic" manner where you don't neccessarily know which of the two you are actually doing. There really isn't an "elegant" solution for this -- you're just trying to do something you shouldn't (force two unrelated implementations through the same interface, just because the interface has the same name, violating a key precept of object-oriented design) and should instead completely separate the implementations.

DesignerX
DesignerX
You could try storing the data descriptor as a memeber of the geometry class.
like :

CDynamicGeometry
{
private :
CDGDescriptor* m_pDGD;

.
.
.

public :
void SetDGD(DGDescriptor* pDGD);
DGDescriptor* GetDGD();
.
.
.
}

You can create a DGD outside the geometry and pass its pointer to the a created geometry and each time you change the outside DGD the inside will change as well
thus your update can now have no arguments.
Or you can just before each update call the SetDGD and set the appropriate DGD. but it doesn't differ much from passing it to update.

There is nothing that can't be solved. Just people that can't solve it. :)

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.