For me derive ShoppingCart from hashtable is a bad choice. ShoppingCart is not a "hashtable", and the semantics of derive(supposing he is using public derive) is "Is-A".
ShoppingCart can derive from Device, but not a HashTable. Device can be a abstract class with public virtual function FindByName();/FindById(); HashTable is definitely a implemetation issue, not an interface one, so it can appear in it's Device's private declaration part as pure virtual function such like GetHashValue();which require derived class to implement. Or it can totally don't appear, because you choose other way to implement the find.
I can't guess out what the authod's guildline is. But mine are:1. respect to the semantics. 2, use more aggregation than inherent.
I am not sure if this apply to Java, because I don't know much of it.
ShoppingCart can derive from Device, but not a HashTable. Device can be a abstract class with public virtual function FindByName();/FindById(); HashTable is definitely a implemetation issue, not an interface one, so it can appear in it's Device's private declaration part as pure virtual function such like GetHashValue();which require derived class to implement. Or it can totally don't appear, because you choose other way to implement the find.
I can't guess out what the authod's guildline is. But mine are:1. respect to the semantics. 2, use more aggregation than inherent.
I am not sure if this apply to Java, because I don't know much of it.