Sign in to follow this  

c++ class design question...

This topic is 4855 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I'm using c++, I've got a couple of main classes for my game, eg Game, Sound, Input, Window, Music,Render Then I got other classes that are specific to each classes listed above. eg Render class uses the Font class, Texture class etc. These other classes are only ever used by the Render class. So I'm wondering, should I put these other classes inside of the Render class or outside? Thanks,

Share this post


Link to post
Share on other sites
My opinion is that they don't belong as nested classes. Even though they are resources used only by a particular system, it's not to the extent that they are integral parts to the operation of that system that they should be nested inside. It's hard to explain, but I simply don't feel it's right :)

For a good example of something that should be made a nested class, take a look at this code. Albeit in Java, it gives a good example of just how integral a class should be to its parent to warrant nesting.

Share this post


Link to post
Share on other sites
my two cents is that if only the implementation of a class requires some library, make the class use a pimpl so that library doesn't have to be exposed to client code.


//Render.h

struct RenderImpl;

class Render
{
private:
RenderImpl * impl;

public:
Render ( );
~ Render ( );
};

//Render.cpp

#include "Texture.h"
#include "Render.h"

struct RenderImpl
{
Texture frontbuffer, backbuffer;
//...
};

Render::Render ( )
{
impl = 0;
impl = new RenderImpl ( );
}

Render::~Render ( )
{
delete impl;
}

Share this post


Link to post
Share on other sites
I would put them inside the renderer to signify that no one else depends on them and thus doesn't need to change when they change. It reduces the clutter and mental overhead. I think in this case the renderer is called an ensemble and it's common I think in OO circles. What would be cool is if in C++ the enclosed classes gained automatic access to their enclosing class. The way it's done now one has to declare the enclosed classes as friends and pass into them the renerer object. Folks might as well destroy the classes and dump their contents into renderer like I'm doing now. But the conceptual/scoped barrier has been destroyed by this. Sometimes you need to access renderer's functions and possibly data in straight forward way yet keep the conceptual enclosure intact. Do others feel like this as well?

Share this post


Link to post
Share on other sites
I have to disagree with JD and agree with Zipster and evolutional in that it should remain outside of the class scope. If a class/struct is used privately by a single, given class, then perhaps I would nest it inside of that class in a private or protected region. Possibly public if I wanted to return information, ie. the Token Pattern.

You should avoid nesting commonly used classes inside of another class, as it can become rather unweildly to type out the type names after a while. I usually have quite long, descriptive type names in my code, so it means a lot to not have to type everything all of the time. Instead, I use namespaces to group related classes belonging to the same subsystem.

For example, I'll have a Graphics, Audio, Input, Application, Network, Intelligence, etc. namespaces. In the Graphics namespace, I'll have a graphics manager class which initializes the graphics hardware and acts as a factory class for creating other classes, such as a bitmap burface or a vertex buffer.

The beauty of namespaces, whether you're working in C++, Java, or C# is that with a simple using/import clause, you can eliminate the need to type out the full-type name. This improves the maintainability of code.

Share this post


Link to post
Share on other sites

This topic is 4855 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this