This quick article describes a mechanism of data hiding that I have been using with some success. Data hiding is a mechanism where information in an object is not accessible to users of the object and, more importantly, not visible to users of the object.

Some data hiding mechanisms built in to the object oriented languages we use are really data protection mechanisms. They don’t hide the data. The C++ “private” and “protected” specifiers just protect the data but they do not hide it. Any article on data hiding that is actually about data protection is bullshit.

I did not make up the mechanism I use. I read about it in a book but cannot remember the name of the book or when I discovered it. it’s also possible that a very experienced co-worker pointed this out to me and it wasn’t in any book. I just don’t know anymore.

Data Hiding means Hiding Data

Take this C++ class as an example of data protection that is sometimes touted as data hiding:

class Test
{
    public:
    test( void ) { m_Value = 0; }
    virtual ~Test( void ) {}

    private:
    int m_Value;
};

This is only protecting the data in the class but any change to the structure of this class requires that the callers and users of this class recompile their code. The members used internally are not all that internal.

The two problems are that data changes in this class require recompiling things that can’t possibly use the data and the implementation details are clearly visible to anyone with the header file in which this resides.

The solution is to make this the class definition:

class Test
{
    public:
    test( void );
    virtual ~Test( void );

    private:
    class CTestImplementation *m_pImplementation;
};

Then go ahead and and create a class for CTestImplementation inside of the .cpp file where the code for the CTest class resides. It’s that simple. Any change to the data members of CTestimplementation are completely hidden from users of the CTest class. It’s possible to provide binary code in a library and then change it and the library without users ever needing to recompile all of the code that uses the CTest class.

Of course there are shortcomings to this mechanism. The most important is that you cannot derive classes from CTest and then have them access the m_pImplementation member variable in a useful way. It is a pointer but the derived class knows nothing about the contents.

I’ve just run into this problem in the train game. I have a base class for the train units, or train cars if you prefer, and I can’t derive specific types of units from it and set their properties in their constructors. I’ll try to write up the solution once I have it. It would be easy to use a template class and make each property a value that can be specified during instantiation but that still exposes the inner-workings of the class. In fact, there is no way for some outside code to create a specific class or object for a specific type of unit or car without knowing how to define it’s properties.

Maybe XML? maybe use data protection instead of data hiding? I’ll know by tomorrow after I work on the problem at home tonight.

Leave a comment