What is the best way to maintain commonly called variables?

[AlwaysLearning]

Lets say there is a class member Z. Z is called several times per iteration of the program. It is never modified outside of its class. How do pros and commercial apps code this?

Now lets say that it is expected that Z will be modified outside the class. How is this usually coded?

[AlwaysLearning]

The current method I have for doing this is using overloaded functions such as GetInfo(), SetInfo(), where the first param is an enum denoting what sort of datatype, and the following params passing in the info to set / get.

IE:

enum dTypes { kColor, kCoordPair };

SetInfo( kColor, r, g, b );

But this leads to tons of overloaded types for all the different types of info to set/get. The other option to consider is to place the private member variables into public space, but this seems very unsafe.

[seymore15074]

If you have a member z that only the class that it is a member of modifies, it would be declared private:

class A
{
//private:
    int z;
public:
    void doit() { z = 10; }
};

If a class member z is modified from outside of the class that it is a member of, then it would typically still be private but have public accessor methods:

class B
{
//private:
    int z;
public:
    int getZ() { return z; }
    void setZ( int i ) { z = i; }
};

Usage:

A a;
a.z = 10;  //error: a.z is private

B b;
b.setZ( 10 ); // b.z = 10 

[helios]

seymore's B's methods are interfaces. If all an interface does is set or get its associated member, as is the case here, it may be a good idea to make the member public.

I think private should be used only if the member shouldn't be directly modified by outsiders, not if it isn't modified. If you make it private and then write stupid interfaces that do nothing, you're just adding red tape you'll have to get through later when you are using the class.

By no means does this mean "never make members private". There are many occasions where privatizing members is the right thing to do. The best example I can think of is the capacity in a vector class.

You should always consider carefully the access rights each member should have.

[z05DSL3A]

The method that Seymore has shown are Accessors, they form part of the Interface of the Class.
Accessor methods provide access to the attibutes (data members) of an object. Directly accessing an object's attributes, as is commonly done in C structures, is discouraged in C++ as it exposes implementation details of the object and degrades encapsulation.

An alternative to the method that Seymore demonstrated is (Attributes as objects):

class X
{
public:
    int             age() const     { return _Age; }
    int&            rAge()          { return _Age; } 
    
    const String&   name() const    { return _Name; }
    String&         rName()         { return _Name; }
private:
    int              _Age;
    String           _Name;
};

^{Attributes as object accessor style}

    X anX;
    anX.rAge() = 12;
    anX.rName() = "Hello";

    cout << anX.name() << anX.age();

^Usage

One weakness of the style is that if you are returning a reference to a basic type, it is not possible to check the validity of the provided value. So you must either create a wrapper class or use the style Seymore has demonstrated. My preferred method would be to create an Age class whit all the consistency checks in its constructor.

The advantage of this style it that it is more consistent the OOP tenet of “the object should do it”. An objects assignment operator (=) should do all the consistency checks, thus centralising them in one place.

[seymore15074]

Although there are times that data members should be public, making them private and adding accessors provides a level of abstraction from the data members themselves. Consider a later change to the software where a certain value must be in a valid range or meet some other constraint.