Re: final methods and classes

  This message is in MIME format. The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---910079544-2104846918-1255368359=:4675
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Mon, 12 Oct 2009, Lew wrote:


Nonetheless, it does contain at least one piece of pretty questionable
advice, namely this one.

I say that despite the fact that i haven't read the book, and don't intend
to. I have, however, come across problems in my work which we could solve
by subclassing an existing class in a third-party library and overriding
some of its methods, in a way that its designers almost certainly did not
intend. If they'd taken JoBo's advice of finalising everything that wasn't
explicitly intended to be overridable, we wouldn't have been able to do
that.

Now, you could counter that what the Blochfather really meant was that you
*should* design your classes to be subclassable, and use final to protect
the bits that must remain unchanged even when subclassed - the emphasis
being on enabling subclassing, not preventing it. If the designers of the
libraries i've had to mangle in this way had done that, then i would still
have been able to fix things by subclassing, and everybody would be happy.
But i think this requires superhuman effort, bordering on ominousness -
they'd have to have anticipated everything someone might usefully do with
their code and provided for it.

I think it's better to make a more permissive approach - finalise the
things that absolutely must not be overriden (of which there will be
fairly few, i would think - mostly security stuff, or very fundamental
support code), and leave the rest open to change, with a large "caveat
overridor" sign on it.

tom

--
Science of a sufficiently advanced form is indistinguishable from magic
---910079544-2104846918-1255368359=:4675--