> you can easily define a private field with a protected get method which amounts to the same thing. It's not though, a method is significantly more cumbersome

> you can easily define a private field with a protected get method which amounts to the same thing. It's not though, a method is significantly more cumbersome. People get lazy and make it a protected field, and probably they themselves remember that the subclass mustn't change it and it's only the poor next person taking over maintenance who gets bitten. > Most Java libraries use it, and it seems to work fine. I mean specifically offering a restricted interface for inheritance by making extensive use of "final", making unstable fields and methods inaccessible etc.. In my experience libraries are rarely careful enough about that, and upgrading a library that you've subclassed from is usually a fraught process. (Wicket is literally the only such library that I've ever been able to fearlessly upgrade) > Used properly, inheritance can certainly lead to much more convenient APIs and code without being prone to misuse. I'm genuinely not convinced. I think if you have interfaces and delegation support, then a well designed non-inheritance API (which might involve e.g. splitting what were single classes in the inheritance version into two) can be just as convenient. > You end up with huge screenfuls of boilerplate which are just forwarding function arguments from one place to another Isn't the whole point of delegation as a language feature to avoid that? Can't you just say "delegating this interface to this member" and then all the methods you didn't specifically define get forwarded? > You upgrade the base libraries and MyButton now has the new features automatically, no code changes required. Or it breaks, because the base library changed in a way you didn't expect / didn't take into account the way you've subclassed it.