RE: Subclass final class (Boolean) ?
RE: Subclass final class (Boolean) ?
- Subject: RE: Subclass final class (Boolean) ?
- From: "Marcin Lukasiak" <email@hidden>
- Date: Tue, 29 Aug 2006 10:00:43 +0200
> 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.
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. 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.
> > 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. 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 - if you still need it because you are a hacker
and just do that for fun - use refrections and change access level to
public.
> >>
> >> 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...
> >>
>
_______________________________________________
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