final methods and classes
in [Java Programming]
|
From: John B. Matthews on 12 Oct 2009 10:33 In article <73cee448-2674-44ef-820b-1ff3a401247c(a)j24g2000yqa.googlegroups.com>, Rze�nik <marcin.rzeznicki(a)gmail.com> wrote: > > 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 I found it exemplary: <http://java.sun.com/docs/books/effective/>. Here are several cogent excerpts: <http://www.ddj.com/java/208403883> <http://www.ddj.com/java/210602264> <http://java.sun.com/docs/books/effective/generics.pdf> > but I can't say for sure because I actually did not read this. If I may amplify on the point, Item 17 in _Effective_Java_ indicates that a class designed for inheritance "must document its self-use of overridable methods." By convention, such documentation typically begins with the phrase "This implementation..." The item cites this example: <http://java.sun.com/javase/6/docs/api/java/util/AbstractCollection.html #remove(java.lang.Object)> The item goes on to discuss several consequences and alternatves. IIUC, the point is to make the heritability choice deliberately and document that choice effectively. -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
From: Andreas Leitgeb on 12 Oct 2009 10:41 Lew <lew(a)lewscanon.com> wrote: >> > 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. Probably just like Rzeźnik, I do have some problems grasping this statement. It seems to me that it means two entirely separate things depending on one's viewpoint: Lew: rather than predict what users are going to do with my API, one had better control them, by using "final" to prevent any possibly "unintended" uses ... Rzeźnik: Rather than predict, what the user really wants to do with the API, rather give them a good base and let them override where they want custom behaviour. Control them by offering them a good API of public and protected methods so they can't do too nasty things. I must admit, that Rzeźnik's point of view is nearer to my own, but then again, I might have misunderstood both.
From: Leif Roar Moldskred on 12 Oct 2009 10:43 Rze??nik <marcin.rzeznicki(a)gmail.com> wrote: > > Yes, a few :-) > First of all: you answered your question already - it is done for > preventing subclasses from redefining them. So it is a mechanism of > enforcing architectural constraints in code. Let's add, very dangerous > one because a mistake here may seriously cripple code re-usability. That might _sound_ omnious, but in practice I find that the only non- trivial code that actually _can_ be gainfully inherited is code that has explicitly been _designed_ to be inherited. If proper thought has gone into making code re-usable, then the use of the "final" keyword won't be a problem as it will be where it should be and not where it shouldn't. If proper thought _hasn't_ gone into making the code re-usable, the use of the "final" keyword isn't likely to be a problem since the code most likely won't be practically reusable anyway. -- Leif Roar Moldskred
From: Rzeźnik on 12 Oct 2009 10:55 On 12 Paź, 16:20, Lew <l...(a)lewscanon.com> wrote: > Lew wrote: > > > 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. > > Rzeźnik wrote: > > 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. > > You didn't read it, yet you feel confident in refuting the arguments > you didn't read? > > Interesting. I wrote "I can't say for sure" and "If there is...". Sincerely, I do not believe that the author of /Effective Java/ prefers "non- heritability". > > FWIW, far from being "useless rubbish", /Effective Java/ is arguably > the most useful book published to help one write idiomatic and, well, > effective Java code. > That might be. Still, your words rather describe it as OO heresy. > Lew: > > > > 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? > > Begging the question.  You assume that 'final' is "contamination" in > order to argue that it's a bad thing. > No, I explained why I believe that final should be used with care. > And I'm not talking about prediction, as you can clearly see from the > passage you quoted, where I say one should NOT predict but control how > the API is used.  So that adds straw man to the fallacies you're using > to attempt to refute my points. > > A rather bald straw man, too.  You took the exact opposite of my > argument in simplest possible terms without even a pretense of logic > or evidence.  For you to use such a weak argument completely > undermines your points. > I am not sure whether we understand each other. Let me reiterate: you said that one should NOT predict, with which I agree. But you clearly do not want to see that 'final' is one endless bag of predictions. Every 'final' you put in your code cries: I PREDICT THAT THIS METHOD/ CLASS HERE IS WRITTEN IN STONE. While sometimes predictions like these may be valid, more often than not they aren't. > Since you said nothing that speaks to my arguments, I cannot but refer > you to what I've already said.  If you have points that refute mine, > or even pretend to, we can continue. > > And do try to read a book before you judge its content.  I referred > you to Mr. Bloch's explanations because they're already far more lucid > and detailed than I can hope to achieve in a Usenet post.  It is not > valid to declare his reasoning "rubbish" simply because it confronts > your prejudices. > I am declaring rubbish not his reasoning per se, but his reasoning as you described it - that may be two different things. Anyway, there is no VALID argument against inheritance in OO language. One may argue that inheritance should be thought out and thoroughly reviewed but one cannot state that it should be abandoned as it is the only way to make sure that OO system is opened for future modifications while being, at the same time, closed so that it is able to execute. The more final you use, the more closed your class hierarchy becomes - which is almost always 'the bad thing'.
From: Rzeźnik on 12 Oct 2009 11:02
On 12 Paź, 16:33, "John B. Matthews" <nos...(a)nospam.invalid> wrote: > In article > <73cee448-2674-44ef-820b-1ff3a4012...(a)j24g2000yqa.googlegroups.com>, > >  Rzeênik <marcin.rzezni...(a)gmail.com> wrote: > > > 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 > > I found it exemplary: <http://java.sun.com/docs/books/effective/>. Here > are several cogent excerpts: > > <http://www.ddj.com/java/208403883> > <http://www.ddj.com/java/210602264> > <http://java.sun.com/docs/books/effective/generics.pdf> > > > but I can't say for sure because I actually did not read this. > > If I may amplify on the point, Item 17 in _Effective_Java_ indicates > that a class designed for inheritance "must document its self-use of > overridable methods." By convention, such documentation typically begins > with the phrase "This implementation..." The item cites this example: > > <http://java.sun.com/javase/6/docs/api/java/util/AbstractCollection.html > #remove(java.lang.Object)> > > The item goes on to discuss several consequences and alternatves. IIUC, > the point is to make the heritability choice deliberately and document > that choice effectively. Yes, so now we are substantially closer to the truth. I agree that you should use inheritance with care and document what you have done and on what basis, and I agree that documentation is probably the only, informal, way to deal with unexpected interactions between base and overridden methods in the Java language. But I do not agree that limiting inheritance severely does any good, but the author does not state it neither. Thank you John. |