Re: Subclass final class (Boolean) ?
Re: Subclass final class (Boolean) ?
- Subject: Re: Subclass final class (Boolean) ?
- From: Ian Joyner <email@hidden>
- Date: Wed, 30 Aug 2006 10:16:40 +1000
On 29/08/2006, at 6:00 PM, Marcin Lukasiak wrote:
On 29/08/2006, at 4:04 AM, Chuck Hill wrote:
On Aug 27, 2006, at 7:28 AM, Ken Anderson wrote:
OK, I'm a little annoyed here because I find the whole concept of
'final' to be ridiculous.
I can see the use of this concept. For example, you may have a
legitimate reason for making your LicenseEvaluator class final.
But the Java API writers have used it with wild conceit.
"Our String
is so perfect, nobody will ever need to extend it!".
Well, that and the fact that String might be a perfectly good
basis for another class.
Ok, so give me any reasonable idea. Final classes have several
different
adventages/disadventages. The most important advantage is that
final methods
can be easily inlined after class is loaded into JVM, especially by
JIT.
This is an implementation and optimization issue not a design issue.
If that is why people are making things final, it is compromising
their designs.
Another thing is that normally good practice is to make esential
classes in
frameworks final. That guaranteees that whenever you will use that
class it
will behave the same way.
Yes, you want subclasses to behave in a consistent manner. That is
the idea behind design by contract, where a redefined routine must
still satisfy the contract (preconditions and postconditions) of the
ancestor interfaces, as well as satisfy the class invariant. This is
flexible while guaranteeing that the intentions of parent classes
(whether inherited by a chain or multiple inheritance, which Java
only has for interfaces) is preserved. Final is a very inflexible
mechanism compared to real design by contract (which should be
obvious is not just putting debugging assertions in your code).
Another point for making String as final is that
java makes many different opitimizations for this class which base
on the
internals of String and assurance of it's behaviour. You can always
use
composition instead of inheritance - marking class as final forces
you to do
it.
Again that is an implementation issue. Design should not be
compromised by implementation - that is going back to the old
languages of the past. However, good implementation properties should
follow from good design and there are lots of compiler optimization
techniques for that. If Java depends on final to optimize, I am less
than impressed. In fact, allowing subclassing may mean that you are
creating less objects (not the reason to subclass), but forcing use
of separate client objects, means more free memory must be searched
to allocate the objects, and then more garbage collection must be done.
That and the rampant use of private methods (as opposed to
protected) mar many Java APIs.
I agree with that too. I hardly ever use private, always
preferring protected. Not being able to get at things in
subclasses goes against the open-closed principle, which
states why you would want to subclass in the first place
rather than use as a client. And that's back to Ken's
original point, because final/private goes against the
flexibility and openness of the OO paradigm. (In fact the
whole public, package-level, protected, private scheme cannot
express intricate relationships between classes where some
are public, but others may be support classes in one or more
other packages.)
That's also intresting. How can it be that final/private goes
against the
flexibility and openness of the OO paradigm? If methods behaviour is
essential for other methods in a class, changing it's bahaviour
needs also
changing all the methods that use it.
Again this is a design by contract thing to ensure consistency. I
agree with Chuck that making things final is the designer of the
class saying that other programmers can't be trusted to ensure that
consistency, which is a tacet admission that DbC is essential. Well,
if they don't that's their problem, but then design by contract is a
much more friendly technique to ensure that consistency than a
blanket ban on extensions. Another point against final is that it is
also used to signify constant, which by DbC means changing would
violate contracts. Static is another annotation that suffers from
several meanings (especially in C++).
That's way sometimes it's good or even
preferred to make a method private. If you really have to access
private
methods - change you design
You don't have the luxury of changing the design of a predefined
library.
- if you still need it because you are a hacker
and just do that for fun
Hacking is good, should not be prevented, because I might actually
know what I'm doing (contrary to the connotation of hacker, that you
mean).
- use refrections and change access level to
public.
I assume you mean reflection can change access level, and that's
horrible too, like with C++ you can cast away constness. Thus
intentions of design (how ever bad they are) can be undermined.
I would like to subclass Boolean so that I can initialize
it (class
method) with a short string (valueOf:"t" instead of
valueOf:"f") and also to return "t" and "f" for toString (or some
other method like toShortString()).
Unfortunately, java.lang.Boolean is marked as final. Is there any
way to get around that?
No, not if you exclude hacking Java by fiddling with the
bootclasspath.
Chuck
To give a little background, I would like to have a custom
WebObjects
type where I can declare the factory method to create the
instance,
and the method to call to get back the string instance. I want to
make it a single character so that I can use a string field with
length=1 instead of length=5 (saving a lot of space).
Oh, and yet another reason I want categories from Objective-C in
Java...
Ian
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden