I find that in a lot of critiques of programming methods, the proposed solutions often contain the implicit assumption that the 'code' is a small to medium codebase with a single developer.
If a sole developer is the only one working on it, of course any approach can contain the complexity.
But, if in the language you are using, the alternative to inheritance is composition via code duplication, then I think that's even worse than inheritance, especially once the code is unleashed on a whole team of maintenance developers.
Who says all that duplicated code will be left in its pristine state, and used only for it's intended 'compositional' purpose? People might start hanging special logic in there or whatever...
Generally, for projects with large teams like this, the less code the better, because that means there's less code for them to screw up.ยน
If that means using inheritance for reuse a bit even if it's not 'pure' OO or whatever, I'd chose that over duplicating code all over the place.
1: I know Java isn't fashionable, but for many reasons, it's perfect for this kind of project.
If a sole developer is the only one working on it, of course any approach can contain the complexity.
But, if in the language you are using, the alternative to inheritance is composition via code duplication, then I think that's even worse than inheritance, especially once the code is unleashed on a whole team of maintenance developers.
Who says all that duplicated code will be left in its pristine state, and used only for it's intended 'compositional' purpose? People might start hanging special logic in there or whatever...
Generally, for projects with large teams like this, the less code the better, because that means there's less code for them to screw up.ยน
If that means using inheritance for reuse a bit even if it's not 'pure' OO or whatever, I'd chose that over duplicating code all over the place.
1: I know Java isn't fashionable, but for many reasons, it's perfect for this kind of project.