RE: Subclass final class (Boolean) ?
RE: Subclass final class (Boolean) ?
- Subject: RE: Subclass final class (Boolean) ?
- From: "Marcin Lukasiak" <email@hidden>
- Date: Wed, 30 Aug 2006 09:57:49 +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.
>
> No, you can't always use composition instead of inheritance.
> Many API methods take a String and your composited class
> won't qualify.
>
I'm saying about your design - you can always use composition instead of
inheritance in your design, when class is marked as final.
Still I don't see resonable case when I would like to extend String
especially because it is immutable so what is the real need that you would
like to extend 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 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.
>
I don't see it the same way. This is true that sometimes people overuse
final for classes that are perfectly good candidates for extending them, but
it is not the case for classes like Boolean or String. I'd also mark them
final because those classes are immutable and are simply primitive types
wrappers (like Integer and so on).
I think other way when marking classes final: Nobody will be so stupid to
extend this class, so I will use final here to say compiler and runtime
system that this will not happen.
Private API are for framework/library/application implementator use - you
should even know that there is any method names X when it's private. Private
API's are private because implementators want to have some internal
structure that they will be able to easily change and usually private API
changes a lot. Normally I'd like to have some parts private to do not think
each time I change internals (because of optimization or whatever) if
someone don't relay on this.
Do you also think that private fields are something to protect from stupid
programmers?
_______________________________________________
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