c++ - help with a 'diamond' situation
- andrew (62/62) Oct 19 2007 Hi,
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