final methods and classes
in [Java Programming]
|
From: Tom Anderson on 13 Oct 2009 18:25 On Mon, 12 Oct 2009, Mike Schilling wrote: > Tom Anderson wrote: >> On Mon, 12 Oct 2009, Lew wrote: >> >>> Lew wrote: >>>>> 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. >>> >>> Rze?nik wrote: >>>> 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. >>> >>> You didn't read it, yet you feel confident in refuting the arguments >>> you didn't read? >>> >>> Interesting. >>> >>> FWIW, far from being "useless rubbish", /Effective Java/ is arguably >>> the most useful book published to help one write idiomatic and, well, >>> effective Java code. >> >> Nonetheless, it does contain at least one piece of pretty questionable >> advice, namely this one. >> >> I say that despite the fact that i haven't read the book, and don't >> intend to. I have, however, come across problems in my work which we >> could solve by subclassing an existing class in a third-party library >> and overriding some of its methods, in a way that its designers >> almost certainly did not intend. If they'd taken JoBo's advice of >> finalising everything that wasn't explicitly intended to be >> overridable, we wouldn't have been able to do that. > > 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. Doubtless. My situation, sadly, was one where the existing third-party code absolutely, positively demands an instance of RepositoryUpdateManagerItemListControllerServletMappingTypeDescriptor. Which is a concrete class. If you want to change what happens when the control of the management of the repository's updates' lists of items served mapped types is described, you'd better set phasers to extend. tom -- skin thinking
From: Arne Vajhøj on 13 Oct 2009 18:36 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. All of JSP pages, servlets, EJB's and connectors use inheritance. Arne
From: Arved Sandstrom on 13 Oct 2009 19:21 Arne Vajhøj wrote: > 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. > > All of JSP pages, servlets, EJB's and connectors use inheritance. > > Arne Servlets and JSPs do, sure, but one is overriding methods in an abstract base class - not exactly what we've been talking about. HttpServlet is also a very well-tested class with well-understood behaviour, nothing like the free-for-all we've been discussing. And like I said, it's not uncommon these days to have J2EE web apps with no JSPs and no user-defined servlets. EJBs: what they do in the background for inheritance is no longer my concern. I supply an interface or two for them to implement; I don't have them extend anything. This is no longer EJB 1.x or 2.x. The discussion has been primarily about whether concrete classes should be final if they are not specifically designed for subclassing. And a nuance of that is, how many of your concrete classes should be designed as potential base classes if you don't have an immediate justification (purpose) for doing so - IOW, do you design them that way just in case. AHS
From: Andreas Leitgeb on 13 Oct 2009 19:25 Tom Anderson <twic(a)urchin.earth.li> wrote: >> The Lew-designer would design streets like trails ... > For future reference, Schienen in english are 'rails' rather than > 'trails'. As in 'Ruby on Rails'. Oh, oups, *blushes* ... yes, correct I meant rails... Thanks for correction. Anyone, to whom my comparison sounded quite strange/absurd... please reread it with "rails" whereever I wrote trails...
From: Arne Vajhøj on 13 Oct 2009 19:34
Arved Sandstrom wrote: > Arne Vajhøj wrote: >> 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. >> >> All of JSP pages, servlets, EJB's and connectors use inheritance. > > Servlets and JSPs do, sure, but one is overriding methods in an abstract > base class - not exactly what we've been talking about. HttpServlet is > also a very well-tested class with well-understood behaviour, nothing > like the free-for-all we've been discussing. And like I said, it's not > uncommon these days to have J2EE web apps with no JSPs and no > user-defined servlets. > > EJBs: what they do in the background for inheritance is no longer my > concern. I supply an interface or two for them to implement; I don't > have them extend anything. This is no longer EJB 1.x or 2.x. > > The discussion has been primarily about whether concrete classes should > be final if they are not specifically designed for subclassing. And a > nuance of that is, how many of your concrete classes should be designed > as potential base classes if you don't have an immediate justification > (purpose) for doing so - IOW, do you design them that way just in case. What I commented on and explicitly quoted said "inheritance (all sorts: implementation and public, concrete base classes and abstract base classes)" and it was suggested that this occurred less frequently in Java EE than in Swing. I can only read what people write. I can not read what they think. Arne |