final methods and classes
in [Java Programming]
|
From: Rzeźnik on 12 Oct 2009 03:46 On 12 Paź, 07:02, "Mike Schilling" <mscottschill...(a)hotmail.com> wrote: > 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. .... if you are ominous If you are ominous then this idea is great. I'd bet you are not. In fact declaring everything as final is worse than most things you can do to cripple program development. IMO every time you are _introducing_ final you have to think deeply. You propose something opposite, final by default, which effectively throws away the open- closed principle which lies at the foundation of OOP. If no concrete class can be redefined, then either your implementation has to be perfect, so no need ever arises to modify its behavior, or you provide no implementations at all. Both cases are quite useless from your clients perspective. Consider: Checkbox <- Button, SecureConnection <- Connection. Now you are proposing to reject similar cases, so every Button implementation will have to either be catch-all scheme (not possible) or go to great lengths to abstract every functionality by means of composition/decoration (either not possible or hardly doable considering that every contained type still suffers from the same illness - one concrete type only). Furthermore, in my opinion program maintenance is done mostly "near leaves" (of inheritance tree) - most ADTs have their implementations already defined at this stage.
From: Rzeźnik on 12 Oct 2009 04:12 On 12 Paź, 04:00, markspace <nos...(a)nowhere.com> wrote: > Mike Schilling wrote: > > Another issue is multi-threading, thread safety and the whole foreign > method bug-a-boo.  Yep, these are very awkward to deal with in the presence of inheritance. There are research-level languages which make an attempt to compose these two concepts: DRAGOON and SINA to name a few. In Eiffel one can find quite interesting, but not so theoretically powerful, concept either (active/passive objects)
From: Mike Schilling on 12 Oct 2009 04:52 Rzeznik wrote: > On 12 Paz, 07:02, "Mike Schilling" <mscottschill...(a)hotmail.com> > wrote: >> 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. > ... if you are ominous > > If you are ominous then this idea is great. I'd bet you are not. I can be pretty threatening at times. Or do you mean "omniscient"?
From: Rzeźnik on 12 Oct 2009 05:27 On 12 Paź, 10:52, "Mike Schilling" <mscottschill...(a)hotmail.com> wrote: > Rzeznik wrote: > > On 12 Paz, 07:02, "Mike Schilling" <mscottschill...(a)hotmail.com> > > wrote: > >> 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. > > ... if you are ominous > > > If you are ominous then this idea is great. I'd bet you are not. > > I can be pretty threatening at times.  Or do you mean "omniscient"? You are omniscient :-) I meant 'omniscient' :-)
From: Lew on 12 Oct 2009 08:28
Rzeźnik wrote: > 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 I know of no good use of constant inheritance. Constants are declared generally as static variables, which are not inherited, exactly, nor should be. > be Sun's SqlDate [sic] <- 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 Terrible example, as it demonstrates why not to inherit a concrete class. But it's hard to say because java.util.Date is such a screwed-up class to start with. Even if classes should sometimes be heritable, screwed-up classes definitely should not be. Using java.sql.Date as an example actually undermines your point. And the standard Java API does not have a class 'SqlDate'. -- Lew |