final methods and classes
in [Java Programming]
|
From: Arved Sandstrom on 12 Oct 2009 22:16 Rzeźnik wrote: > On 12 Paź, 14:33, Lew <no...(a)lewscanon.com> wrote: >> Roedy Green wrote: >>> On Sun, 11 Oct 2009 15:38:17 -0700 (PDT), Lionel van den Berg >>> <lion...(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. >>> seehttp://mindprod.com/jgloss/final.html >>> For APIs you don't publish, I think you should make anything final you >>> can for documentation purposes. >> For APIs you do publish, you should make every class final that you intend not >> to be heritable, which should be most of the concrete classes. >> > > Lew, I am sorry to say this, but this does not make any sense. It goes > against the very spirit of OOP. If you write your published APIs in a > way you described then your APIs are useless in the face of design > changes. You can get away with this as long as you write programs for > yourself only, or programs with very short life cycle. Why do you fear > inheritance so much? I know of so called FBC problem, I am well aware > what it means, but it is no argument against inheritance. I don't think anyone is arguing against inheritance in certain situations. What matters though is the type of inheritance, and who it is exposed to. Is it public inheritance or implementation inheritance? Are we providing abstract classes or concrete classes to inherit from? In another post I mentioned an app I help maintain where roughly a quarter of about 2850 core classes are subclasses, or about 660 of them. With the exception of about 30 custom exception classes (public inheritance from Exception or subclasses thereof) and about 15 tag handlers that inherit from Facelets TagHandler, and a tiny number of other cases, all of the inheritance is internal to the application. Over 90 percent of it in fact. There aren't even five classes from external libraries that we actually sub-class. Point being, this is only a medium-sized J2EE app, but it's reasonably complex. We use several dozen third-party APIs (libraries). And yet we've seen the need to inherit from only 3 or 4 external classes. Based on my experience this is not unusual. IOW, inheritance (all sorts: implementation and public, concrete base classes and abstract base classes) may get used a fair bit in the _implementation_ of an application or a library, but that doesn't mean that it gets used a lot across API boundaries. I certainly have never seen that APIs expect a lot of it to occur, or that it's considered to be desirable as a general rule. Some exceptions to that observation are somewhat ubiquitous - java.lang.Exception and subclasses as concrete base classes, or javax.servlet.http.HttpServlet as an abstract base class. This simply goes to show that _sometimes_ inheritance of a class in a public API is a reasonable way to get things done. Other posters have commented on this - there simply are better ways of making your library extensible than to make it possible for clients to subclass your classes willy-nilly. At most I can see the argument for carefully crafted abstract base classes in certain situations - I see considerably less use for non-final public concrete classes. AHS
From: markspace on 13 Oct 2009 00:02 Arved Sandstrom wrote: > IOW, inheritance (all sorts: implementation and public, concrete base > classes and abstract base classes) may get used a fair bit in the > _implementation_ of an application or a library, but that doesn't mean > that it gets used a lot across API boundaries. This may also depend on the style of the application and the API. For example, I'd expect a lot more inheritance in a Swing application than what you observed in your J2EE app.
From: markspace on 13 Oct 2009 00:05 Tom Anderson wrote: > I suspected this, but am disappointed. I would love 'ominous' to become > a technical software engineering term. > > public final void append(ominous String s) ... No no no... sheesh. Use annotations: @Ominous public final void append( String s ) ...
From: Mike Schilling on 13 Oct 2009 01:50 markspace wrote: > Arved Sandstrom wrote: > >> IOW, inheritance (all sorts: implementation and public, concrete >> base >> classes and abstract base classes) may get used a fair bit in the >> _implementation_ of an application or a library, but that doesn't >> mean that it gets used a lot across API boundaries. > > > This may also depend on the style of the application and the API. > For > example, I'd expect a lot more inheritance in a Swing application > than > what you observed in your J2EE app. Inheritance gets used a lot for callbacks, which are quite common in Swing and other event-driven programs. That is, there's usuually an interface that defines the callback with a standard implementation that that provides default behaviiors, and almost all user implementors subclass it. In J2EE, for instance, all servlet classes are subclasses of HttpServlet, so that they can be called when requests arive. (In this case, there isn't even an interface.)
From: RedGrittyBrick on 13 Oct 2009 05:03
Rzeźnik wrote: > On 12 Paź, 14:32, Lew <no...(a)lewscanon.com> wrote: >> >> Read the item in /Effective Java/ referenced upthread for a >> thorough explanation of why to prefer non-heritability. >> > > 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. The author supports his recommendations with thorough explanations and with examples that illustrate the reasons for, and benefits of, the approaches recommended. There are two free sample chapters at http://java.sun.com/developer/Books/effectivejava/ I think you'd enjoy reading the whole book. -- RGB |