final methods and classes
in [Java Programming]
|
From: Rzeźnik on 12 Oct 2009 17:12 On 12 Paź, 22:17, "Mike Schilling" <mscottschill...(a)hotmail.com> wrote: > 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. Ok, you are right.  At any rate, > if all you want is to re-use code, that's not an is-a relationship. What makes you think so? Consider SavedGame <- File. while it is clear that every SavedGame is_a file you certainly do not want to expose that fact to clients (if you did they could, let's say, save it anywhere they like or overwrite contents blindly) while still retain ability of working with files - sheer code re-use. Would you say that SavedGame has_a File instead?
From: Andreas Leitgeb on 12 Oct 2009 17:26 Lew <lew(a)lewscanon.com> wrote: > One is to permit inheritance, and if so, design > the class accordingly. What makes a class "designed for inheritence"? Of course documentation - that would go without saying. What else? Anything else? Is it the existence of at least one private field with accessor methods, just to show derivers who's the boss?
From: Rzeźnik on 12 Oct 2009 17:31 On 12 Paź, 22:46, Lew <l...(a)lewscanon.com> wrote: > 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. > Ok, I understand. > > 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. > You are a little illogical here, you know. Why do not 'forbid' such erratic behavior? Here your "don't use" seems to be just a guideline, matter of documentation. Am I mistaken? > 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: Well, perhaps if you did not ignore my "If you want almost anything to be final ("Every time you omit 'final' in a class declaration you should consider carefully") you are in fact arguing AGAINST inheritance in my opinion" and commented on it, we could finally get somewhere. (In fact we did, see below before you reply) > > 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? > See above. By the way, you slightly changed your tone from 'inheritance not preferred' to 'I am against the abuse' - and I can, more or less, accept that better. > 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. > When I have a chance to get my hands on it, I will.
From: Joshua Cranmer on 12 Oct 2009 19:21 On 10/12/2009 05:12 PM, Rzeźnik wrote: > What makes you think so? Consider SavedGame<- File. while it is clear > that every SavedGame is_a file you certainly do not want to expose > that fact to clients (if you did they could, let's say, save it > anywhere they like or overwrite contents blindly) while still retain > ability of working with files - sheer code re-use. Would you say that > SavedGame has_a File instead? is-a has a very specific meaning in terms of OOP. If A is-a B, that means every instance of class A is also an instance of class B, and, perhaps the most important part, every operation in class B is valid for objects of type A (public class Square extends Rectangle fails this part quite miserably). My copy of /Effective C++/ would call what you want "is-implemented-in-terms-of"--which is handled by composition or (in C++) private inheritance. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
From: Mike Schilling on 12 Oct 2009 19:55
Rzeznik wrote: > On 12 Paz, 22:17, "Mike Schilling" <mscottschill...(a)hotmail.com> > wrote: >> 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. > > Ok, you are right. > > At any rate, >> if all you want is to re-use code, that's not an is-a relationship. > > What makes you think so? Consider SavedGame <- File. while it is clear > that every SavedGame is_a file you certainly do not want to expose > that fact to clients (if you did they could, let's say, save it > anywhere they like or overwrite contents blindly) while still retain > ability of working with files - sheer code re-use. Would you say that > SavedGame has_a File instead? You said it yourself:: you don't want to expose to clients that SavedGame is a File, because this will let them call arbitrary File methods on a saved game. This you don't want to derive SavedGame from File, or, to say it another way, there's no is-a relationship. What you would do instead is to give SavedGame a field that's a File and delegate some of the SavedGame methods to it (delete, possibly rename, etc.) That's precisely a has-a relationship. |