final methods and classes
in [Java Programming]
|
From: Arved Sandstrom on 13 Oct 2009 20:01 Arne Vajhøj wrote: > 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 I stand corrected if we are talking old-style EJB 2.x and JSP applications in terms of that one statement I made. In the context of the sub-thread it's not the kind of inheritance we were talking about even then, but as you say, you (and Mike and markspace) were responding to that one specific statement. AHS
From: Dave Searles on 13 Oct 2009 20:32 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) ... That would be much nicer than that awful clunky @NotNull ... or was it @NonNull?
From: Dave Searles on 13 Oct 2009 20:33 Tom Anderson wrote: > Trails means badly-defined paths that go to obscure places and are > difficult to follow. As in 'The Java Tutorials [...] are organized into > "trails"'. I disagree with the former, and with the implied insult to Sun's Java Tutorial website.
From: Mike Schilling on 13 Oct 2009 20:37 Tom Anderson wrote: > On Mon, 12 Oct 2009, Mike Schilling wrote: >> >> 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. Agreed that when you gotta hack, you gotta hack.
From: Mike Schilling on 13 Oct 2009 20:40
Arved Sandstrom wrote: > 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. In an ideal world I might do things like that just in case; in the real one, I barely have time to do what's required as well as I'd like. |