I was basing my answer solely on your specific example. I think that says something: You can only make these decisions on a case by case basis. Attempting to form wide reaching generalisations will only lead to mistakes and frustration. Best course of action is to try and understand the thought processes a 'pro' goes through when making these types of decisions. For this you should check out books on oo that tell you about the principles the drive patterns and make them successful; I've mentioned Heads First Design Patterns but there are others. Refactoring by Martin fowler gets
great acclaim (comments are worth a look too) although I've never read it personally.
Re: inheritance/composition.
Composition, Composition and Composition! Inheritance just doesn't work in the long run. When I first started oo (in C++) I said to my lecturer "All the best classes are small, aren't they?" and he agreed. Unlike a lot of my misconceptions of best practice oo, that one has stayed true. So keep your classes, small, and numerous.
I was particularly badly burnt recently with the composite pattern. A known drawback to this pattern is just to cram more and more behaviour into the classes and, predictably, I did exactly that. One rewrite later I'd solved 50% of the problem but only realized there was another 50% to solve when I was near the end. I discovered a bug and realised it was actually impossible to solve it without changing superclasses really high up -- very bad oo indeed. I was suffering from what some might call "Primitive Obsession".
I'm on the next rewrite now and I'm confident I've got it right this time, I think I've learn that lesson now. But then again I thought that last time. So what I'm doing now is writing the whole thing up in UML and then developing by prototype; that is, leaving as many of the extras and details out and trying to implement the minimum you can that will still prove a oo design to be successful. If it isn't hopefully you haven't lost too much time and if it is you can easily continue to build on your prototype and you are likely to have something to show sooner. This is a bit like iterative development.