🚀 go-pugleaf

I'm a little shy asking this question.  This is a slightly long post but it 
should be easy to follow.  I'm trying to change the design of an area of 
code to use __interface classes.  Eventually I may go COM but for now these 
interfaces are purely internal to get the benefits of implementation 
isolation and reference counting.  I've been using interfaces for a while so 
the concept isn't new to me but I've always stayed away from the following 
case.  I am curious how other developers handle this.

Let's say I have a base interface.  For simplicity let's call this interface 
INode.  The interfaces that inherit from it are IFolder, IFile, and maybe 
others.  Here is what the classes might look like:

  __interface INode : public IInterface
  {
    public:
      virtual String GetName()=0;
  };

  typedef DelphiInterface<INode> _di_INode;

  __interface IFolder : public INode
  {
    public:
      virtual _di_INode AddChild(_di_INode Child)=0;
      virtual _di_INode GetChild(unsigned Index)=0;
      virtual unsigned GetChildCount()=0;
  };

  typedef DelphiInterface<IFolder> _di_IFolder;

  __interface IFile : public INode
  {
    public:
      virtual unsigned __int64 GetFileSize()=0;
  };

  typedef DelphiInterface<IFile> _di_IFile;

This looks okay (to me at least) and programmers using it can understand the 
hierarchy.  However, my conceptual problem is in understanding how to code 
the implementation.  If I code the classes with the exact same structure I 
would get this:

  class TNode : public TInterfacedObject, public INode
  {
    private:
      String fName;

    public:
      // Implementation of IUnknown
      // (QueryInterface, AddRef, and Release)

      // Implementation of INode
      virtual String GetName();
  };

  class TFolder : public TNode, public IFolder
  {
    private:
      // supporting data

    public:
      // Implementation of IFolder
      virtual _di_INode AddChild(_di_INode Child);
      virtual _di_INode GetChild(unsigned Index);
      virtual unsigned GetChildCount();
  };

  class TFile : public TNode, public IFile
  {
    private:
      // supporting data

    public:
      // Implementation of IFile
      virtual unsigned __int64 GetFileSize();
  };

It's obvious there are problems with this structure since TFolder and TFile 
will have two INode inherited classes.  Constructing a TFolder at this point 
would yield an abstract class that doesn't have an implementation of 
IUnknown's methods nor INode's.  I can add the methods to the descendant 
that simply call their inherited equivalents but I don't think the vtables 
match up correctly in that situation.  IOW, I *don't* think this is the 
correct approach.

Another way I can create the structure is thusly:

  class TNode : public TInterfacedObject, public INode
  {
    private:
      String fName;

    public:
      // Implementation of IUnknown
      // (QueryInterface, AddRef, and Release)

      // Implementation of INode
      virtual String GetName();
  };

  class TFolder : public TInterfacedObject, public IFolder
  {
    private:
      String fName;
      // other supporting data

    public:
      // Implementation of IUnknown
      // (QueryInterface, AddRef, and Release)

      // Implementation of INode
      virtual String GetName();

      // Implementation of IFolder
      virtual _di_INode AddChild(_di_INode Child);
      virtual _di_INode GetChild(unsigned Index);
      virtual unsigned GetChildCount();
  };

  class TFile : public TInterfacedObject, public IFile
  {
    private:
      String fName;
      // other supporting data

    public:
      // Implementation of IUnknown
      // (QueryInterface, AddRef, and Release)

      // Implementation of INode
      virtual String GetName();

      // Implementation of IFile
      virtual unsigned __int64 GetFileSize();
  };

This works correctly all around but it requires that I duplicate code in 
each class.  This can lead to errors and changes in one area of code not 
propogating to other areas.  IOW, not very good code reuse or OOD.

So my question is how do other developers code something like this?  Should 
the interfaces be changed to some other structure?  Are interface 
hierarchies only for COM versioning (like recordset15 and recordset20 of 
ADO)?

As I reached this point in my post another idea came to me.  I could 
separate the implementation classes from the data classes.  Something like 
this:

  class TNode
  {
    public:
      String Name;
  };

  class TFolder : public TNode { ... };
  class TFile : public TNode { ... };

  class ImplFolder : public TInterfacedObject, public IFolder
  {
    private:
      TFolder fFolder;

    public:
      virtual String GetName() { return fFolder.Name; }

      // ...
  };

  class ImplFile : public TInterfacedObject, public IFile
  {
    private:
      TFile fFile;

    public:
      virtual String GetName() { return fFile.Name; }

      // ...
  };

This requires only a little extra code and doesn't violate the code reuse 
issues.  Could this be the favored approach that other people employ?  Or am 
I making this too complicated?

Thanks for reading through this and for any words of wisdom.

- Clayton