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....




Reply via email to