Simple c++ Question...

[Roose Bolton of the Dreadfort]

Okay.

Say I have a base class which has some physics objects in its private members so;

NOTE - THIS IS A MINIMAL EXAMPLE.

BaseObject Header:

class BaseObject
{
        BaseObject();
        ~BaseObject();

        b2Body& GetBody();
        b2BodyDef& GetBodyDef();
        b2FixtureDef& GetFixtureDef();
        b2PolygonShape& GetPolygon();
        b2World& GetWorld();

private:
        b2Body* mBody;
        b2BodyDef mBodyDef;
        b2FixtureDef mFixtureDef;
        b2PolygonShape mPolygon;
        b2World *mWorld;
};
 

and I have a class that inherits it so;

DerivedObject Header:

class DerivedObject: public BaseObject
{

public:
        DerivedObject(void);
        ~DerivedObject(void);

private:


};
 

DerivedObject code:

DerivedObject ::DerivedObject ()
        : BaseObject()
{

this->GetBody() = this->GetWorld().CreateBody(this->GetBodyDef());

}
 

Now, as with Box2d, it requires lots of initiating the variables. C++ does not allow me to use them as I use above, it gives errors like 'no operator matches =' and 'const this' errors, but I don't know how else to do it? I don't want to make them all public in the BaseClass.. is there any syntax to get around this?

I have use Protected, and that works perfectly and is not accessible to the outside world, but is there any syntax to be able to use the above logic with private get/setters?

[eXpl0it3r]

It doesn't make much sense to declare the base class member variables private and then try to access them through class functions. Just declare them as protected and you can access them directly within the derived class.

IMHO this-> shouldn't be used for calling member functions if it's not mandatory, because if you handle the scopes correctly (no globals etc.), then it's clear that if you call a function without any prefix, that you're calling the function of the current class.

[Roose Bolton of the Dreadfort]

It doesn't make much sense to declare the base class member variables private and then try to access them through class functions. Just declare them as protected and you can access them directly within the derived class.

IMHO this-> shouldn't be used for calling member functions if it's not mandatory, because if you handle the scopes correctly (no globals etc.), then it's clear that if you call a function without any prefix, that you're calling the function of the current class.

Yeah it looks tidier with out it anyway

When WOULD this-> be mantatory???

[FRex]

b2World::CreateBody returns and takes pointer, you can't assign pointer to reference, can take adress of reference to get pointer

[Sui]

It doesn't make much sense to declare the base class member variables private and then try to access them through class functions. Just declare them as protected and you can access them directly within the derived class.

From an OO design perspective, this isn't a good idea. Ideally classes should not be able to access member variables of their parent, otherwise changes in logic in the base class will impact subclasses. For example, if you needed to create an object on first call or delegate responsibility to another class you would have to make the member variables private and use a function. The subclass code would then have to be changed also.

Ideally you should use protected functions if you want to expose data to a subclass.

There could be a slight performance penalty with this, if they are not inlined by the compiler.

[eXpl0it3r]

From an OO design perspective, this isn't a good idea. Ideally classes should not be able to access member variables of their parent, otherwise changes in logic in the base class will impact subclasses. For example, if you needed to create an object on first call or delegate responsibility to another class you would have to make the member variables private and use a function. The subclass code would then have to be changed also.

Although I do get your point, I'd still say this largely depends on what you do. For me there's no problem to think of a base class + derived class as one thing and thus I won't feel uncomfortable, if I change something on the base, which will affect the derived classes. Having to define functions just to access the content that actually already lies within the class, to me doesn't make much sense and really the only advantage it'd have is a bit a nice interface.
So as long as the outcome of having the base class completely separated from the derived classes is large enough, for me it's often a waste of time.

But I'm not an expert on OOP and I don't quite know what experts would advise here.
Do you have any citations on that topic?

[Sui]

It was just the purist in me coming out. Encapsulation and all that.

For really simple accessors I tend to bung them in the header file. That way they are typically inlined by the compiler. Moving them to the CPP file does cause a bit more compilation but doesn't break the subclasses.

If you're using .NET, you can declare properties and their member variables on the same line, which is nice. You get the benefit of a nice interface that you can change without separate functions. If you go down the separate function route later, the interface is not altered.

A couple of books I've found useful on OO are:

Refactoring (Fowler)
Applying UML and Patterns (Larman)   - a bit dry, but useful

Over the years I have read a whole bunch of books, best practice documents etc. I couldn't really say explicitly where I first read about encapsulation and separation of responsibility.

I'm certainly far from perfect. I have embarrassing (code) skeletons in my closet, like everyone else!
Just spreading the good word. :-)

Good OO practice is definitely more critical in team development or when developing libraries.

[Nexus]

I agree with Sui, I tend to avoid protected member variables.

Encapsulation against the derived class may be meaningful, too. I already had the case where the internal representation changed, but I could keep the protected API. In many cases, there is no full access to the variables necessary, so specific functions can limit and track access.