final methods and classes
in [Java Programming]
|
From: Mike Schilling on 12 Oct 2009 15:32 Tom Anderson wrote: > On Mon, 12 Oct 2009, Lew 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. >> >> 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. > > Nonetheless, it does contain at least one piece of pretty questionable > advice, namely this one. > > I say that despite the fact that i haven't read the book, and don't > intend to. I have, however, come across problems in my work which we > could solve by subclassing an existing class in a third-party library > and overriding some of its methods, in a way that its designers > almost certainly did not intend. If they'd taken JoBo's advice of > finalising everything that wasn't explicitly intended to be > overridable, we wouldn't have been able to do that. Another bit of useful advice from Effective Java: prefer aggregation. No one said you can't re-use code, but inheritance, particularly unintended inheritance, is not necessarily the best way to do it.
From: Rzeźnik on 12 Oct 2009 16:01 On 12 Paź, 21:32, "Mike Schilling" <mscottschill...(a)hotmail.com> wrote: > > Another bit of useful advice from Effective Java: prefer aggregation.  No > one said you can't re-use code, but inheritance, particularly unintended > inheritance, is not necessarily the best way to do it. You cannot really _prefer_ one to another in general because they represent different relationships. If this Effective Java states it exactly so then it is another example of how misleading this book is. Correct way of saying what you just might be: prefer aggregation to inheritance IFF both of them are valid relations between types in your particular case.
From: Rzeźnik on 12 Oct 2009 16:03 On 12 Paź, 21:06, Andreas Leitgeb <a...(a)gamma.logic.tuwien.ac.at> wrote: > > Could you two just agree to disagree? Perhaps :-) Really funny post - thanks :-)
From: Mike Schilling on 12 Oct 2009 16:17 Rzeznik wrote: > On 12 Paz, 21:32, "Mike Schilling" <mscottschill...(a)hotmail.com> > wrote: > >> >> Another bit of useful advice from Effective Java: prefer >> aggregation. No one said you can't re-use code, but inheritance, >> particularly unintended inheritance, is not necessarily the best way >> to do it. > > You cannot really _prefer_ one to another in general because they > represent different relationships. If this Effective Java states it > exactly so then it is another example of how misleading this book is. I caution you not to judge the book by a two-word paraphrase. At any rate, if all you want is to re-use code, that's not an is-a relationship.
From: Lew on 12 Oct 2009 16:46
Rzeźnik wrote: > If you so strongly believe that what you are advocating for is > 'recommended practice' then it is not strange that anything I've said It is not a belief but a verifiable fact. I am advocating a practice, and it's been recommended by leading authors in the Java world, ergo it's a recommended practice. > makes no sense to you. Point is that "prohibiting inheritance" is not Not strange, perhaps, but also not true. What you are saying makes perfect sense to me, it's only that I don't completely agree with you. Your mistake is to confuse disagreement with lack of understanding. > a recommended practice. If you don't design a class to be thread safe > but allow it to be you are in far bigger troubles - do you recommend > putting 'synchronized' everywhere? > No, I don't. I recommend that you either design a class for multi- threaded use or don't use it in a multi-threaded way. That is cognate to the discussion here. Lew wrote: >> So let's try again - drop the straw man and circular arguments. > I see you haven't stopped doing that. Stop misstating my point then arguing against the misstatement. I am not advocating prohibiting inheritance per se. Stop presenting that as if I were. It's intellectually dishonest. Let me put that in simple terms again in case you don't understand it: I do not advocate prohibiting inheritance. I advocate thinking carefully about whether a class should be heritable, and either designing the class to be so or else prohibiting it. There are two options in what I'm proposing, both based on thinking carefully about what you will permit. One is to permit inheritance, and if so, design the class accordingly. The alternative is to prohibit inheritance. Either/or. Not just one. I am not against inheritance. I am against the abuse of inheritance. I do not advocate prohibiting inheritance in any blanket way. Do you understand that now? Or are you going to misstate my point again? Maybe you should break down and actually read the referenced chapters in /Effective Java/ to get the complete discussion - again, more cohesively and comprehensively presented than I have done - instead of attacking points I'm not making and attributing those points to me. -- Lew This sig (signature passage) copyright (c) 2009 by Lew Bloch. All rights reserved. Reproduction of this sig in any format, electronic or otherwise, without express written permission from the copyright holder is forbidden. |