Yes, please. The rule is either design and document for inheritance, or
prohibit it. If you "flat-out disagree" with that, then you must think
there are times when one does not prohibit inheritance, nor designs and
documents for it.
Yes.
As i said:
If you need to prevent overriding or inheritance to enforce certain
invariants, then fine, that's the thing to do. If you want to provide
explicit extension hooks to guide and ease the job of subclassing, that's
great. But otherwise, leave the choice in the hands of the client
programmer.
I am puzzled at how you can support such a notion. Shouldn't you do one
or the other, always?
In an ideal world, yes. But this is not such a world.
If you need to prohibit inheritance to enforce invariants, do it. Here i
agree with Joshua Bloch. If there are specific extension points that you
want to build into a class, then design and document for them. Here, we
also agree.
But what about a class or method where it isn't *necessary* to prohibit
inheritance, but where you don't have a specific intent for an extension
point. Here, he says that either you design and document for inheritance
anyway, or you prohibit it. I say you just leave it.
In an ideal world, we'd have the time and foresight to take the Bloch
approach, and make sure that every single doesn't-need-to-be-final method
in our classes was safely overridable. In reality, we don't. That means
our choice is really between leaving them overridable, or slapping a
precautionary 'final' on them. I say do the former; my understanding is
that Bloch says to do the latter.
My argument for this is that in practice, allowing methods to be
overridden is useful. As i mentioned in my earlier post, it's let us
customise a framework in ways that its designers didn't anticipate, and
that we found very useful. Conversely, i don't think it's dangerous -
there seems to be an implicit idea that letting programmers override
methods which weren't specificially designed to be overridden will
inevitably get them into all sorts of trouble, and i don't buy that. My
experience tells me that trouble is certainly not inevitable. It's
possible - you can get into trouble when subclassing, but then you can do
that writing fresh code of your own anyway. Thus, i feel that
final-by-default is just an unnecessary restriction of other programmers'
freedom.
tom
