On Fri, Aug 22, 2008 at 11:45 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 22, 2008 at 10:34 AM, Sean Owen <[EMAIL PROTECTED]> wrote: > > > You are right, I am not sure it makes any significant difference in > > speed. The only situation where I know it can help is in ProGuard > > optimization as it can perform inlining as a result. The better > > argument is just for correctness -- if you aren't sure you set up the > > class for subclassing, prohibit it. > > > I would come to *exactly* the opposite conclusion. Until you have *PROVED* > that the performance is need from exactly that piece of code, don't > prohibit > subclassing. +101. I've had some experiences with final classes where I had to extend their functionality. I had to resort to clever class loader tricks to get around them e.g. use same package+class name and put them in the war where Tomcat would look first before looking into the jar in the lib directory. There are other pains where a public class depends on a package private class for a large amount of functionality. It is very hard to rewrite the functionality of the package private class when extending the public class. The only easy solution is to either copy/paste the original code or use the above class loader trick. > > > > > But if there are helpful reasons to make classes extendable, leave it so, > > yes. > > > The strongest reason is that other people are clever and are likely to come > up with something good. > > Interfaces (or abstracts as Karl would prefer) are fine and dandy, but lots > of stuff isn't worth building the whole framework of classes around, but is > still worth testing with mocks. > + 101 again. *Please* do not make classes final until you have a very very compelling reason. -- Regards, Shalin Shekhar Mangar.
