Archives
D Programming
DD.gnu digitalmars.D digitalmars.D.bugs digitalmars.D.dtl digitalmars.D.dwt digitalmars.D.announce digitalmars.D.learn digitalmars.D.debugger C/C++ Programming
c++c++.announce c++.atl c++.beta c++.chat c++.command-line c++.dos c++.dos.16-bits c++.dos.32-bits c++.idde c++.mfc c++.rtl c++.stl c++.stl.hp c++.stl.port c++.stl.sgi c++.stlsoft c++.windows c++.windows.16-bits c++.windows.32-bits c++.wxwindows digitalmars.empire digitalmars.DMDScript electronics |
c++ - help with a 'diamond' situation
Hi, I try to understand the decoupled design based on interfaces but I see that some problems arise and I have not found a place where this is discussed. The client code works with interface classes, decoupled from their implementation: class IItem { public: virtual ~IItem() { } virtual bool get_name(string& name) = 0; // some common properties virtual bool get_size(unsigned long &size) = 0; } class IAItem : public IItem { public: // methods specific to IAItem } class IBItem : public IItem { public: // methods specific to IBItem } // client code uses IItem* pItem = ... string name; pItem->get_name(name); usigned long size; pItem->get_size(size); The implementation will want to have a common abstract class derived from IItem where these common properties are implemented: class ItemAbstract : public IItem { public: virtual bool get_name(string& name) { ... } // some common properties implemented virtual bool get_size(unsigned long &size) { .... } } but the problem appears with the implementation of the IAItem or IBItem: class AItem : public IAItem, public ItemAbstract { public: // implementation of IAItem } IItem IAItem ItemAbstract AItem this implementation is ambigous because the AItem class will have 2 instances of IItem (one inherited through IAItem and one through the ItemAbstract) so i need that: class IAItem : virtual public IItem class ItemAbstract : virtual public IItem But, although this works, overseeing (for the moment) that fact that this will give an warning saying that AItem inherits the ItemAbstract methods through dominance, the problem i see is that at one moment I needed to change the initial design of the interface. What if I could not do that, i.e. maybe those interfaces are from a library or something, hence read-only for me (the implementor) ? It feels like the design is not OK but in the same way, since what's it's trying to achieve is so simple, I can't see another way. What's your opinion ? Thanks. Oct 19 2007
|