   inheritance vs composition?
  Suppose I want to add a little component to my classclass KidInputGetter{    TickInput lastinput;    protected:    const TickInput& GetInput() const {return lastinput;}    public:    void SetInput(const TickInput& input) {lastinput = input;}    virtual ~KidInputGetter(){}};I think I have two options:Inheritanceclass Pickory: public Entity, public KidInputGetter{};or composition (I'd need to change GetInput to public obviously)class Pickory: public Entity{    KidInputGetter mypinput;   public:    void SetInput(const TickInput& newinput) {myinput.SetInput(newinput);}};The main advice I've seen on these forums is to favor composition over inheritance. Also, I'm a bit hesitant to use multiple inheritance, because it is confusing.On the other hand, the composition approach requires extra code. Also, in the first example, I can just pass around a KidInputGetter* (or equivalent shared pointer in practice), but the composition approach appears to make polymorphism very difficult.What should I do?   
  You might need to explain more clearly what you're doing since your names are... not terribly descriptive.Generally though, this looks like a candidate for composition. If you need polymorphic dispatch on the composite entity make it a shared pointer and be done with it. No need to make things more complex than they need to be.   ;  The only reason that you'd use inheritance (i.e. class Pickory: public Entity, public KidInputGetter) is if you have to -- if Pickory is a KidInputGetter.If Pickory isn't a polymorphic variety of KidInputGetter, then a has a relationship (composition) is probably better.   ;Quote:Original post by TelastynYou might need to explain more clearly what you're doing since your names are... not terribly descriptive.Generally though, this looks like a candidate for composition. If you need polymorphic dispatch on the composite entity make it a shared pointer and be done with it. No need to make things more complex than they need to be.I'm confused. Do you mean making Pickory contain a shared_ptr<KidInputGetter>? That seems like it is even more complex.What I want to do is to have a function that works on any class containing a KidInputGetter. If I use inheritance, then I can just use polymorphism directly.   ;  From the code posted, KidInputGetter doesn't have any polymorphic functions (except the destructor, so you can delete derived types through KidInputGetter pointers?) -- so there doesn't seem to be a need for it.What is a KidInputGetter? What is a Pickory? What data do they work on? What's the use cases?If Pickory has a KidInputGetter, but you need to plug the KidInputGetter into something else, then one option is to give Pickory a GetInputGetter function.   ;  Well I have a function which takes a boost::weak_ptr<KidInputGetter>. I'd like to be able to pass it a smart pointer to an instance of Pickory.It just seems weird to use composition because it requires so much extra code.-declaration of KidInputGetter pointer-initialization of the pointer-SetInput function-GetInputGetter functionAnd all of that is duplicated for every class which has a KidInputGetter. It seems like such a waste.Here's an example of useboost::shared_ptr<Pickory> temp(new Pickory(myManager));myManager->AddEntity(temp); //takes a shared_ptr<Entity>myManager->pipeKidInput(temp); //takes a weak_ptr<KidInputGetter>;Quote:Original post by StoryyellerWhat I want to do is to have a function that works on any class containing a KidInputGetter. If I use inheritance, then I can just use polymorphism directly.So you want to use an interface? In C++, that's done by deriving from an (abstract) base class.However, as Hodgman already asked, if you can give some concrete use-cases, instead of vague, non-descriptive class names, we might be able to give more specific advice. It's hard to tell what's the best approach with such little information.   ;  What we actually need is your specific use case. It seems that you are looking for the One True Answer; you want to know which option is the one to always use in similar situations.In reality its likely that subtle differences in requirement could drive us to choose one option or the other. But, for adding components, I rarely do class BaseWithComponentA. This is because if I then need component b, I have to write BaseWithComponentB and BaseWithComponentAAndComponentB. The pain continues if you have component C. This is where composition makes the most sense.   ;Quote:Original post by speciesUnknownWhat we actually need is your specific use case. It seems that you are looking for the One True Answer; you want to know which option is the one to always use in similar situations.In reality its likely that subtle differences in requirement could drive us to choose one option or the other. But, for adding components, I rarely do class BaseWithComponentA. This is because if I then need component b, I have to write BaseWithComponentB and BaseWithComponentAAndComponentB. The pain continues if you have component C. This is where composition makes the most sense.Why do you need a BaseWithComponentAandB? Can't you just inherit both separately?Also, so if I only have one component, inheritance makes the most sense, but if I have multiple ones, composition is better?As for the interface thing, I was originally going to make KidInputGetter an abstract interface class, but then I realized that any class using it would want to store the last input, so I figured I might as well add that functionality to the base, rather then duplicating it in every class that inherits from it.Sorry I'm being so vague. There's a lot of code in my project and I'm not sure what parts I should be posting.   ;  We don't particularly care about your code in this case. We want to know what you're trying to do. It looks like you have some woefully over-engineered monstrosity.Quote:I'm confused. Do you mean making Pickory contain a shared_ptr<KidInputGetter>? That seems like it is even more complex.Yes, that's what I mean. If you want other parts of the code to refer to part of the composite class, that's what you do. Sure, it's more complex. But what you're saying is you need that complexity for some reason. You're going to have to implement it somehow, and that's a pretty straightforward way of doing it.Quote:What I want to do is to have a function that works on any class containing a KidInputGetter. If I use inheritance, then I can just use polymorphism directly.template <class T>void DoStuff(T arg){    arg.KidInputGetter(stuff);}But frankly this smells of over-engineering something fierce. What are your requirements?