Virtual classes with different behavior
Author
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;
}
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 ?
and also the two classes which inherit CDynamicGeometry ?
Author
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.
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.
i suppose you could create a interface, say, Renderable, and make theses two geometries implement it.
this way you can always render Renderable objects.
this way you can always render Renderable objects.
Author
ehmmm... sure ;-)
The strategy (GoF) is exactly an interface "like" pattern, besides that is not the dillema...
The strategy (GoF) is exactly an interface "like" pattern, besides that is not the dillema...
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.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
