Archived

This topic is now archived and is closed to further replies.

GroZZleR

Self-Contained Classes : Yes? No? Do I have the right term? =P

Recommended Posts

Hey all, I''m writing a simple puzzle game, and I was wondering if you had any input as far as writing self-contained classes. For example, is it better to do something like
  
CPuzzle
{
public:
void Render(void);
};

CMenu
{
public:
void Render(void);
};
  
(Obviously they''ll have more than just that. Or is it better to do something like
  
CRender
{
public
void RenderPuzzle(CPuzzle Puzzle);
void RenderMenu(CMenu Menu);
};
  
Is there a difference? What are the pros / cons? Thanks guys.

Share this post


Link to post
Share on other sites
It''s a design question, so here''s my two cents:

The difference is where the coupling is done. In the first example, you could add a third type of object without modifying CRender, and that''s good.

In the second example, you could change renderer without modifying any of your other classes. However, this could also be done with templates/run-time polymorphism in your first example, if two renderers had the same public interface and they were passed to Render().

So, I think the first example is much better.

Cédric

Share this post


Link to post
Share on other sites
quote:
Original post by cedricl
It''s a design question, so here''s my two cents:

The difference is where the coupling is done. In the first example, you could add a third type of object without modifying CRender, and that''s good.

But in the first example, if you change how you draw anything, you have to modify all the classes that do any rendering.

So both ways have some positives and negatives. Personally I go for the 2nd way, because I believe that individual objects shouldn''t need to know anything about rendering.



[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files | My stuff ]

Share this post


Link to post
Share on other sites
I see your point, and in the original post, I agree to some extent.

The OP''s comparison is not entirely symetrical. The way I would do it, Render would be an abstraction layer between the graphic API and CPuzzle. CPuzzle.Render would have to accept an argument of type CRender (or some templated stuff to allow different renderers), and call abstract function like Line() or Rectangle().

The second example is not extensible at all. If you want to create a new object, you have to modify CRender. I really don''t like that.

BTW, if you do go for the second example, you should use function overloading, and always pass by reference.

Cédric

Share this post


Link to post
Share on other sites
quote:
Original post by Kylotan
But in the first example, if you change how you draw anything, you have to modify all the classes that do any rendering.

So both ways have some positives and negatives. Personally I go for the 2nd way, because I believe that individual objects shouldn''t need to know anything about rendering.



I believe that the way to make this completely OO would be use a base class for everything that needs to be rendered, which all of the other rendered classes are derived from.

For example:

  
class CRenderedObject
{
public:
virtual void Render();
};

class CPuzzle : public CRenderedObject
{
public:
virtual void Render();
//virtual in case you want to derive from this class later

};

class CMenu : public CRenderedObject
{
public:
virtual void Render();
};


Therefore if you have any rendering code that is shared between CPuzzle and CMenu you can just call CRenderedObject::Render().


void CPuzzle::Render()
{
CRenderedObject::Render();
//class specific rendering code here
}


I personally wouldn''t go quite so OO just for something simple like this, it looks a lot like MFC and I would only use it in a complex polymorphic class system with 100''s of classes. I think that your two examples would be fine for 99% of apps.

Comments?

Share this post


Link to post
Share on other sites
OOPO
Object Oriented Programming Overkill

Hehe, the two examples you posted are the same. Either way you are creating custom Render functions for each thing. The only reason you would the second one would be if you wanted to have all rendering code in your game loop have CRender at the start of it, which is OOPO. Along with Neosmyle''s example for most everything.

Share this post


Link to post
Share on other sites