final methods and classes
in [Java Programming]
|
From: Arved Sandstrom on 13 Oct 2009 20:57 Mike Schilling wrote: > 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. Well, you and me both. So by default I lock down my concrete classes by having all instance fields private and minimizing the amount of accessors, for starters - no extra effort involved with that. Truth be told, for internal non-public code, I don't often explicitly mark concrete classes as final, simply because anyone who decides to subclass one of my classes has to do public inheritance anyway...IOW, they're welcome to it but I don't see how much good it'll do 'em. But for a public API I'd be marking concrete classes as final unless I explicitly designed them for inheritance. And I can't think of too many situations where I'd be doing this for concrete base classes as opposed to abstract base classes. AHS
From: Mike Schilling on 13 Oct 2009 21:38 Arved Sandstrom wrote: > > But for a public API I'd be marking concrete classes as final unless > I > explicitly designed them for inheritance. And I can't think of too > many situations where I'd be doing this for concrete base classes as > opposed to abstract base classes. That's where I wind up too.
From: Andreas Leitgeb on 14 Oct 2009 05:08 Mike Schilling <mscottschilling(a)hotmail.com> wrote: > Andreas Leitgeb wrote: >> What makes a class "designed for inheritence"? >> Of course documentation - that would go without saying. >> What else? Anything else? > Being very careful about public and protected methods calling other public > and protected methods, so that overriding them selectively doesn't lead to > havoc. I've never heard, that the act of overriding itself led to havoc, so I guess it would depend on *how* they'd be overridden by someone. Then whose havoc is it that is being led to? The API provider's or the one whose overrides did it? Maybe there is a cultural difference between people who feel more responsible for what their customers might possibly do and other's who rather grant their customers freedom and demand some reason. Is it the same cultural difference that manifests in tags like: "Warning! does not enable user to fly" on a superman costume?
From: Rzeźnik on 14 Oct 2009 06:38 On 14 Paź, 11:08, Andreas Leitgeb <a...(a)gamma.logic.tuwien.ac.at> wrote: > Mike Schilling <mscottschill...(a)hotmail.com> wrote: > > Andreas Leitgeb wrote: > >> What makes a class "designed for inheritence"? > >> Of course documentation -  that would go without saying. > >> What else?  Anything else? > > Being very careful about public and protected methods calling other  public > > and protected methods, so that overriding them selectively doesn't lead to > > havoc. > > I've never heard, that the act of overriding itself led to havoc, so I guess > it would depend on *how* they'd be overridden by someone.  Then whose havoc > is it that is being led to?  The API provider's or the one whose overrides > did it? > Unfortunately, it can. It does not matter who is stricken by havoc :-) You can read about it starting from: http://en.wikipedia.org/wiki/Fragile_base_class If you are theoretically inclined you may find 'Stata-Guttag groups' interesting (I believe Szyperski in his 'Component software: beyond object-oriented programming' has good description, but it's been a long time since I last read his book) Still, all these problems should not make you believe that inheritance is devil's kin :-) > Maybe there is a cultural difference between people who feel more responsible > for what their customers might possibly do and other's who rather grant their > customers freedom and demand some reason. > > Is it the same cultural difference that manifests in tags like: "Warning! does > not enable user to fly" on a superman costume? That's interesting interpretation indeed. Another might be: it may have something to do with open-source vs proprietary. If you rely on open-source software you are, I think, inclined to experiment more with your libs - like trying wildest inheritance patterns imaginable. Even if something went wrong, you can always check the source and see why it went wrong, debug it comfortably, fix a bug etc. Proprietary software users have to rely mostly on docs and guidelines, so inheritance for them is asking for troubles as it is quite hard to document that stuff properly (so they cannot fully rely on vendor's docs) and it inflicts additional costs to (so vendor might choose to mark things final mostly). Maybe that's why they tend to perceive inheritance as something suspicious. But I am just guessing.
From: Mike Schilling on 14 Oct 2009 10:48
Andreas Leitgeb wrote: > Mike Schilling <mscottschilling(a)hotmail.com> wrote: >> Andreas Leitgeb wrote: >>> What makes a class "designed for inheritence"? >>> Of course documentation - that would go without saying. >>> What else? Anything else? > >> Being very careful about public and protected methods calling other >> public and protected methods, so that overriding them selectively >> doesn't lead to havoc. > > I've never heard, that the act of overriding itself led to havoc, so > I guess it would depend on *how* they'd be overridden by someone. > Then whose havoc is it that is being led to? The API provider's or > the one whose overrides did it? Do you really not know what I mean? Fine I'll be more explicit. 1. If A can't be subclassed successfully by reading its documentation, but requires experimenting do determine how A was implemented, A hasn't been designed to be subclassed. 2. If re-implementing A while adhering to its contract will break its subclasses, A hasn't been designed to be subclassed.. Either way, A should be defined as final. Becasue the alternative is that V2 of the library can break existing clients. |