Re: final methods and classes
Andreas Leitgeb wrote:
Lew <lew@lewscanon.com> wrote:
As an API writer (that is, one who writes a class intended for use)
one should control how the API is used, not predict it.
Probably just like Rzeznik, I do have some problems grasping
this statement.
It seems to me that it means two entirely separate things depending
on one's viewpoint:
Lew: rather than predict what users are going to do with my API,
one had better control them, by using "final" to prevent any
possibly "unintended" uses ...
Rzeznik: Rather than predict, what the user really wants to do with
the API, rather give them a good base and let them override where
they want custom behaviour. Control them by offering them a good
API of public and protected methods so they can't do too nasty
things.
Mike: Unless I've been careful to design class Foo for inheritance, I'm
likely to break its (unintended by me) subclasses if I reimplement it in
version 2. Rather than risk this, I'll mark it final. If someone really
needs the functionaly of subclassing it, they can achieve it safely using
aggregation, which V2.0 is very unlikely to break. And as a matter of
brute fact, I'm very unlikely to derive one concrete class from another.