Why is almost everything in the API final
snfuchs at gmx.de
Mon Sep 2 11:00:40 PDT 2013
Fabrizio Giudici wrote:
> On Mon, 02 Sep 2013 18:10:17 +0200, Christian Schudt
> <christian.schudt at gmx.de> wrote:
>> I agree with that and I also recommend to have a look at "Item 17:
>> Design and document for inheritance or else prohibit it" from
>> Effective Java.
>> It explains the burden and dangers of non-final design quite well.
This applies only to the perfect (final) framework.
In other words for a framework without bugs and a framework, where all
possible usecases are considered by its author.
I agree that there are dangers, when overwriting methods. But in my
experience they rarely matter. Once created methods rarely change in a
way that affects subclasses. And for major releases of the framework you
have to test your application anyway.
If you develop a framework, where methods have complex interdependencies
you should step back and write smaller, more manageable methods.
There are always legitimate reasons to overwrite methods. e.G.: To work
around a bug in the framework. To trigger events, when a certain method
has been called, to write debug info in a logfile,.... And no I don't
want to roll out my own fork of jdk to my customers to do this....
More information about the openjfx-dev