Fabrizio Giudici wrote:
On Mon, 02 Sep 2013 18:10:17 +0200, Christian Schudt
<christian.sch...@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.
http://uet.vnu.edu.vn/~chauttm/e-books/java/Effective.Java.2nd.Edition.May.2008.3000th.Release.pdf
It explains the burden and dangers of non-final design quite well.
+1
-1
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....