final methods and classes
in [Java Programming]
|
From: Lew on 11 Oct 2009 22:30 Lionel van den Berg wrote: >>> 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. Arne Vajhøj wrote: >> In my opinion none it is a leftover from the very early days of Java. >> >> See: >> http://www.ibm.com/developerworks/java/library/j-jtp1029.html Sorry about the accidental post. I had intended to write: Excellent link, Arne. However, that very article gives many good reasons for using the 'final' keyword, contradicting your notion that there aren't good reasons for it. From an API writer's perspective, that is, anyone writing classes intended to be used, 'final' on a class or method indicates that it should not, and therefore cannot be extended / overridden. As Mr. Goetz said in the referenced article, this decision should be documented (in the Javadocs). Josh Bloch in /Effective Java/ suggests that one should prefer composition to inheritance, and that inheritance is somewhat abused. ("Design and document for inheritance or else prohibit it") He advises to make classes final unless you explicitly and properly make them heritable. -- Lew
From: Lionel van den Berg on 11 Oct 2009 23:00 On Oct 12, 12:30 pm, Lew <no...(a)lewscanon.com> wrote: > Lionel van den Berg wrote: > > >>> 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. > Arne Vajhøj wrote: > >> In my opinion none it is a leftover from the very early days of Java. > > >> See: > >> http://www.ibm.com/developerworks/java/library/j-jtp1029.html > > Sorry about the accidental post. I had intended to write: > > Excellent link, Arne. However, that very article gives many good reasons for > using the 'final' keyword, contradicting your notion that there aren't good > reasons for it. > > From an API writer's perspective, that is, anyone writing classes intended to > be used, 'final' on a class or method indicates that it should not, and > therefore cannot be extended / overridden. As Mr. Goetz said in the > referenced article, this decision should be documented (in the Javadocs). > > Josh Bloch in /Effective Java/ suggests that one should prefer composition to > inheritance, and that inheritance is somewhat abused. ("Design and document > for inheritance or else prohibit it") He advises to make classes final unless > you explicitly and properly make them heritable. Some excellent comments and discussion here. I am of the above view, if I see inheritance or consider using it I scrutinise the design to death to make sure inheritance really is the appropriate solution. The majority of classes have no need to be inherited. I have in the past used inheritance to find later how confusing it can make a design, and now I'm seeing it used frequently for no reason other than code re-use, which is definitely bad. Thanks for the comments and links. Lionel.
From: Mike Schilling on 12 Oct 2009 01:02 markspace wrote: > Mike Schilling wrote: >> Lionel van den Berg wrote: >>> Hi all, >>> >>> 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. >> >> Some classes have not been designed to be extensible (either as a >> deliberate choice or because the time wasn't taken to make >> extensibility work correctly.) > > > This is the one I would emphasize. "Either design for inheritance > or > prevent it." Effective Java, I believe, by Joshua Bloch. There's a rule of thumb I was taught long ago that one shouldn't derive one concrete class from another. I've found it to be excellent advice. I can't explain particularly well why doing so is a bad idea in general, but whenever I've been tempted to break the rule, I've found that creating an abstract superclass (or a hierarchy of such superclasses) from which all concrete classes are derived has solved problems the concrete-derived-from-concrete design created. I don't think it's far wrong to say: Declare all concrete classes as final.
From: Roedy Green on 12 Oct 2009 02:38 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. -- Roedy Green Canadian Mind Products http://mindprod.com I advocate that super programmers who can juggle vastly more complex balls than average guys can, should be banned, by management, from dragging the average crowd into system complexity zones where the whole team will start to drown. ~ Jan V.
From: Rzeźnik on 12 Oct 2009 03:16
On 12 Paź, 05:00, Lionel van den Berg <lion...(a)gmail.com> wrote: > On Oct 12, 12:30 pm, Lew <no...(a)lewscanon.com> wrote: > > > > > Lionel van den Berg wrote: > > > >>> 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. > > Arne Vajhøj wrote: > > >> In my opinion none it is a leftover from the very early days of Java.. > > > >> See: > > >>  http://www.ibm.com/developerworks/java/library/j-jtp1029.html > > > Sorry about the accidental post.  I had intended to write: > > > Excellent link, Arne.  However, that very article gives many good reasons for > > using the 'final' keyword, contradicting your notion that there aren't good > > reasons for it. > > >  From an API writer's perspective, that is, anyone writing classes intended to > > be used, 'final' on a class or method indicates that it should not, and > > therefore cannot be extended / overridden.  As Mr. Goetz said in the > > referenced article, this decision should be documented (in the Javadocs). > > > Josh Bloch in /Effective Java/ suggests that one should prefer composition to > > inheritance, and that inheritance is somewhat abused.  ("Design and document > > for inheritance or else prohibit it")  He advises to make classes final unless > > you explicitly and properly make them heritable. > > Some excellent comments and discussion here. > > I am of the above view, if I see inheritance or consider using it I > scrutinise the design to death to make sure inheritance really is the > appropriate solution. The majority of classes have no need to be > inherited. > > I have in the past used inheritance to find later how confusing it can > make a design, and now I'm seeing it used frequently for no reason > other than code re-use, which is definitely bad. > No Lionel, it's oversimplification. So called implementation inheritance or utility inheritance has its uses. Probably you perceive it as bad because it is mostly used in systems that have multiple inheritance or mixins (consider ArrayStack <- Stack, Array which presumably inherits interface from Stack and implementation from 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 be Sun's SqlDate <- 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 suggest you should read B.Meyer "Object Oriented Software Construction". The author gives very precise inheritance taxonomy which you might find interesting. |