Re: Subclass final class (Boolean) ?
Re: Subclass final class (Boolean) ?
- Subject: Re: Subclass final class (Boolean) ?
- From: Chuck Hill <email@hidden>
- Date: Tue, 29 Aug 2006 14:49:53 -0700
On Aug 29, 2006, at 1:00 AM, 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.
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.
No, you can't always use composition instead of inheritance. Many
API methods take a String and your composited class won't qualify.
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 interesting. How can it be that final/private goes
against the
flexibility and openness of the OO paradigm? If methods behavior is
essential for other methods in a class, changing it's behavior
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 reflections and change access level to
public.
That is conceit you are describing, not good design. Good design is
thinking, "I will build this clearly, and encapsulate the concepts,
and implement it in terms of these concepts." Private API is the
conceit of a Designer thinking, "I know better than any Developer who
will ever use this class, so I will keep the dangerous parts safe
from their unskilled hands." Public methods are the API for the end
users of the class. Protected methods form the API for extenders of
the class. Private API is just inconsiderate unless it is hiding
some particularly brittle and nasty implementation. What if you
don't need to change a private method, but only call it? You can't.
So if you subclass a class with many private methods, you end up
having to re-implement much of it rather than tweak the bit you were
concerned with.
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems. http://www.global-village.net/products/practical_webobjects
_______________________________________________
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