final methods and classes
in [Java Programming]
|
From: Lew on 12 Oct 2009 14:08 Lew wrote: >> And the standard Java API does not have a class 'SqlDate'. > Rzeźnik wrote: > We all know what we are talking about. > Precision good. Sloppiness bad. Correction provided for the benefit of readers present and future who very well might not know what you're talking about. -- Lew
From: Rzeźnik on 12 Oct 2009 14:16 On 12 Paź, 19:54, Lew <l...(a)lewscanon.com> wrote: > Rzeźnik wrote: > > 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. > > Your point here is incorrect.  Declaring a class 'final' is not a > prediction, it's a constraint.  You are not predicting that "this > method / class is written in stone" with 'final'.  You are forcing it > to be.  No prediction involved, just control.  I advocate dictating > the use, not predicting it. Here you present just word juggling. If I were to reply, I'd have repeat myself > > > 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 > > I described it thus: > > >> 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. > > In other words, "Read the book.  See for yourself." > > What part do you disagree with, that you should consider carefully, or > with the reasoning expressed in the book to which I referred? > You already know what it is I am disagreeing with: "explanation of why to prefer non-heritability". This strongly suggests that use of inheritance should be perceived as an anomaly rather than day-to-day tool. Also, from what John Matthews and others presented, the author's claims that "non-heritability" is somehow preferred are nowhere to be found. > > no VALID argument against inheritance in OO language. One may argue > > No one is arguing against inheritance, just its abuse.  Read the > book.  Decide for yourself. > 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. Or, in other words, you seem to want to eliminate the abuse of inheritance so much that you'd rather forbid inheritance in the first place. > > that inheritance should be thought out and thoroughly reviewed but one > > Ummm, yeah-ah. > > > 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 > > Straw man, straw man, straw man.  I also am not arguing against > inheritance, or for its abandonment, only against its abuse. > OK, let's replace abandonment with serious limitation. > > 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'. > > I am simply saying that one should design and document for inheritance > (of concrete classes), or else prohibit it, in line with and for the > reasons stated in /Effective Java/. > If you could only remove the part "or else prohibit it"... > If you don't design a class to be heritable but allow it to be, then > you have problems. Not necessarily  You cannot use the circular argument that a > recommended practice for object-oriented programming violates the > principles of O-O without demonstrating that it does, in fact, do so. > If you so strongly believe that what you are advocating for is 'recommended practice' then it is not strange that anything I've said makes no sense to you. Point is that "prohibiting inheritance" is not 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? > So let's try again - drop the straw man and circular arguments. > > -- > Lew
From: Rzeźnik on 12 Oct 2009 14:26 On 12 Paź, 20:00, Lew <l...(a)lewscanon.com> wrote: > Rzeźnik wrote: > > So I judge 'final' to be usable when > > it is obviously known that class will not be redefined ever > > If you declare a class 'final', then it is obviously known that it > will not be subclassed. How is it KNOWN? It is not known - you cannot know this except for a few cases, and even in these cases it is not strictly 'knowledge' but rather educated guess.  ("Redefined" does not apply here - we're > talking about inheritance, not redefinition.) Technically you are correct, although redefinition (of a method or an invariant) by a subclass is the most interesting case here. I think that even you do not deem extension without redefinition to be THAT bad.  You're putting the cart > before the horse. > > No prediction needed - it is a dictatorship. > > If you do not declare a class 'final', then you had better darn well > make sure that it's conditioned for inheritance.  If you do not > declare a class 'final', you are giving permission for it to be > inherited.  No prediction needed. > Only if you know all possible use cases in which your class is going to be used. Not feasible. > The API writer does not predict, he permits. > So he better permits wisely. It is surely safer to forbid everything, but that makes API less usable (up to and beyond the point of being useless).
From: Andreas Leitgeb on 12 Oct 2009 15:06 Lew <lew(a)lewscanon.com> wrote: > If you declare a class 'final', then it is obviously known that it > will not be subclassed. [...] > No prediction needed - it is a dictatorship. The prediction is what a developer may do for user's wishes. The Lew-designer would design streets like trails - only at switches is it even possible to change direction. Every possible future need for direction-changes has to be *predicted* at trail-build time, or the trail cars just will not (dictatorship-enforced) be able to turn right, later, where the trail passes by his own house. The Rzeźnik-designer designs streets as they are, at the risk of each car to slip off the road, maybe even fall down the bridge, at the car-driver's freedom and full responsibility. And in Lew's view, Rzeźnik probably would design trails like streets, and let the trains go any direction never meant for them to go... Could you two just agree to disagree?
From: Mike Schilling on 12 Oct 2009 15:30
Andreas Leitgeb wrote: > 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 Rzeznik, 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 ... > > Rzeznik: 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. Mike: Unless I've been careful to design class Foo for inheritance, I'm likely to break its (unintended by me) subclasses if I reimplement it in version 2. Rather than risk this, I'll mark it final. If someone really needs the functionaly of subclassing it, they can achieve it safely using aggregation, which V2.0 is very unlikely to break. And as a matter of brute fact, I'm very unlikely to derive one concrete class from another. |