Good question, thanks. I think I was conflating both -- but I think both apply. The benefit of is-a hierarchies -- perhaps the only big benefit (to be weighed

Good question, thanks. I think I was conflating both -- but I think both apply. The benefit of is-a hierarchies -- perhaps the only big benefit (to be weighed against all the other alternatives available) -- is that it solves for making the next 'adaptation' as simple as possible. It optimizes for the very next extension step. It is slightly less conceptually complex to extend an object than to composite a new feature. It does that at the cost of complexity and brittleness. But in both the real world and and in source maintenance this is occasionally useful. Let's say I'm a startup practicing lean and experimentation as much as possible. What I want is a framework that allows me to tweak things with as few steps as possible. What I don't want is to refactor every time I want to do an experiment. Anyway, code I think generally should model our understanding of the problem space and the real world concepts in play. Extension is not a bad way to begin modeling that understanding.. Because growing the first steps (even though they will clutter because there is nothing encouraging orthogonality in OOP besides one's own sense of cleanliness) is often good for the growth of our understanding.