Re: final methods and classes
Rze??nik wrote:
On 12 Pa??, 14:33, Lew <no...@lewscanon.com> wrote:
Roedy Green wrote:
On Sun, 11 Oct 2009 15:38:17 -0700 (PDT), Lionel van den Berg
<lion...@gmail.com> wrote, quoted or indirectly quoted someone who
said :
Just wondering what arguments there are out there for making methods
and classes final when they are not expected to be overridden/
extended? Typically I would make them final, but when I'm doing code
reviews I don't raise this as an issue because I see it is relatively
trivial.
seehttp://mindprod.com/jgloss/final.html
For APIs you don't publish, I think you should make anything final you
can for documentation purposes.
For APIs you do publish, you should make every class final that you intend not
to be heritable, which should be most of the concrete classes.
Lew, I am sorry to say this, but this does not make any sense. It goes
against the very spirit of OOP. If you write your published APIs in a
way you described then your APIs are useless in the face of design
changes. You can get away with this as long as you write programs for
yourself only, or programs with very short life cycle. Why do you fear
inheritance so much? I know of so called FBC problem, I am well aware
what it means, but it is no argument against inheritance.
For the final-by-default approach to work it has to be combined with the
use of interfaces rather than classes in argument type declarations.
A programmer who needs to substitute a different implementation can do
so by writing a class that implements the interface, possibly using
composition to reuse some of the implementation. Eclipse automates
generation of delegate methods.
Making a class final and then requiring a reference to that class as an
argument, rather than a reference to an interface it implements, would
indeed create problems.
Patricia