> > > 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....
-- -1 as well. One of the major points of Java is that it is an object oriented language. By making things final you kill one of the major O.O. benefits, that is subclassing. You can do composition but it's not the same thing as you can not pass in the object to methods that accept the composed class. Though, I also agree that it should be difficult to create a framework where all use cases of subclassing a class are accounted for, especially when you have to preserve backwards compatibility. Best regards, Pedro Duque Vieira
