TITLE: Separation of implementaion and interface


[ If it seems like we get this theme repeatedly, we do. It is something
  we don't spend much effort implementing, yet has important consequences.
  This won't be the last time either ... -adc ]


PROBLEM: c-goetze@u-aizu.ac.jp (Christian F. Goetze)

One thing that bothers me most in C++ is that you do not have a neat
separation between interface and implementation of classes.

Usually, you will have the private parts of classes divulged in the
header files 

So, I am wondering if the following "trick" is a generally accepted
C++ idiom:

class A {
   private:
      void *private_data;
   public:
}


RESPONSE: rmartin@rcmcon.com (Robert Martin), 21 Sept 94

This is not a generally accepted trick.  It breaks type safety and
forces you to do nasty unsafe downcasts from void* 

The "accepted" way to separate implementation from interface is to
separate them.  i.e. put them in separate classes.

class AbstractBase
{
  public:
    // public interface only.  probably pure virtual function.
    // no protected or private interface at all.
};

class ConcreteImplementation : public AbstractBase
{
  public:
    // declarations of the interfaces.
  
  private:
    // the private stuff.
};

Now, all the clients of ConcreteImplementation are independent of it.
They all use AbstractBase instead.  This is an application of a
pattern known as "Bridge" which inverts the dependencies between
client and server so that the client does not depend upon the server
at all.  i.e. you can change the server without recompiling the
client.

This is also an example of the Open/Closed principle.  i.e. clients of
AbstractBase can be extended to do different things by deriving new
subclasses of AbstractBase rather than by modifying any client code.