final methods and classes
in [Java Programming]
|
From: Lew on 12 Oct 2009 08:32 Mike Schilling wrote: >> Declare all concrete classes as final. Rzeźnik wrote: > ... if you are ominous I don't understand. > If you are ominous [?] then this idea is great. I'd bet you are not. In > fact declaring everything as final is worse than most things you can > do to cripple program development. IMO every time you are > _introducing_ final you have to think deeply. Every time you omit 'final' in a class declaration you should consider carefully. Read the item in /Effective Java/ referenced upthread for a thorough explanation of why to prefer non-heritability. As an API writer (that is, one who writes a class intended for use) one should control how the API is used, not predict it. -- Lew
From: Lew on 12 Oct 2009 08:32 Rzeźnik wrote: > On 12 Paź, 04:00, markspace <nos...(a)nowhere.com> wrote: >> Mike Schilling wrote: > >> Another issue is multi-threading, thread safety and the whole foreign >> method bug-a-boo. > > Yep, these are very awkward to deal with in the presence of > inheritance. There are research-level languages which make an attempt > to compose these two concepts: DRAGOON and SINA to name a few. In > Eiffel one can find quite interesting, but not so theoretically > powerful, concept either (active/passive objects) Which isn't so very helpful when programming in Java. -- Lew
From: Lew on 12 Oct 2009 08:33 Roedy Green wrote: > On Sun, 11 Oct 2009 15:38:17 -0700 (PDT), Lionel van den Berg > <lionelv(a)gmail.com> wrote, quoted or indirectly quoted someone who > said : > >> Just wondering what arguments there are out there for making methods >> and classes final when they are not expected to be overridden/ >> extended? Typically I would make them final, but when I'm doing code >> reviews I don't raise this as an issue because I see it is relatively >> trivial. > > see http://mindprod.com/jgloss/final.html > > For APIs you don't publish, I think you should make anything final you > can for documentation purposes. For APIs you do publish, you should make every class final that you intend not to be heritable, which should be most of the concrete classes. -- Lew
From: Rzeźnik on 12 Oct 2009 09:02 On 12 Paź, 14:28, Lew <no...(a)lewscanon.com> wrote: > Rzeźnik wrote: > > Array). But even in a language limited to single inheritance you > > should find good uses for this kind of inheritance. One such example > > might be, common in Java world, constants inheritance. Another might > > I know of no good use of constant inheritance.  Constants are declared > generally as static variables, which are not inherited, exactly, nor should be. > > > be Sun's SqlDate [sic] <- Date (although they have been widely criticized > > for this, but that's had nothing to do with their choice of > > inheritance per se. They just screwed interchangeability up)  I really > > Terrible example, as it demonstrates why not to inherit a concrete class. > > But it's hard to say because java.util.Date is such a screwed-up class to > start with.  Even if classes should sometimes be heritable, screwed-up classes > definitely should not be.  Using java.sql.Date as an example actually > undermines your point. ??? Well, I don't know what is your point against java.util.Date and I do not know what makes my example so bad in your eyes. It is perfectly valid example of concept of implementation inheritance (how it was actually carried out is irrelevant) > > And the standard Java API does not have a class 'SqlDate'. > We all know what we are talking about. > -- > Lew
From: Rzeźnik on 12 Oct 2009 09:07
On 12 Paź, 14:32, Lew <no...(a)lewscanon.com> wrote: > Mike Schilling wrote: > >>  Declare all concrete classes as final. > Rzeźnik wrote: > > ... if you are ominous > > I don't understand. I meant "omniscient", my mistake. > > > If you are ominous [?] then this idea is great. I'd bet you are not. In > > fact declaring everything as final is worse than most things you can > > do to cripple program development. IMO every time you are > > _introducing_ final you have to think deeply. > > Every time you omit 'final' in a class declaration you should consider > carefully.  Read the item in /Effective Java/ referenced upthread for a > thorough explanation of why to prefer non-heritability. > If there is such guidance there then the book is useless rubbish - but I can't say for sure because I actually did not read this. > As an API writer (that is, one who writes a class intended for use) one should > control how the API is used, not predict it. > Agreed. So if we are on the same page - we do you try to predict how your API will be used and 'contaminate' it with 'final's? |