Exactly.
On Sep 17, 11:34 am, Joshua Marinacci <[EMAIL PROTECTED]> wrote:
> By using this factory system it means that the client developer cannot
> subclass the component. They can only instantiate and configure it.
>
> On Sep 17, 2008, at 12:31 AM, [EMAIL PROTECTED] wrote:
>
>
>
> > Hi Alexey,
>
> > In the end, don't you expose exactly the same API whether you derive
> > from JComponent or return JComponent via an accessor method?
>
> > I'm not necessarily arguing against doing it, I'm just playing devil's
> > advocate!
>
> > Craig.
>
> > On Sep 17, 3:54 am, Alexey <[EMAIL PROTECTED]> wrote:
> >> The component may very well return a JComponent object, but that
> >> would
> >> be all that's known by the client, unless it resorts to reflection.
> >> So by only guaranteeing the bare minimum of API necessary for a
> >> layout
> >> manager to handle the resulting object, Ken allows himself the
> >> freedom
> >> to completely change the implementation.
>
> >> On Sep 16, 3:02 pm, "[EMAIL PROTECTED]"
>
> >> <[EMAIL PROTECTED]> wrote:
> >>> Hi Ken,
>
> >>> First things first, congratulations on doing a great job with the
> >>> Mac
> >>> widgets and thank you for releasing them under a commerically
> >>> friendly
> >>> open source license!
>
> >>> I guess the question I would ask is what benefit do you think you
> >>> are
> >>> getting by not deriving from JComponent? Since getComponent() still
> >>> returns a JComponent, the client can still access all of it's public
> >>> API. And developers being developers, they will traverse the
> >>> component
> >>> hierarchy to find the Swing class that they want to manipulate,
> >>> use it
> >>> anyway, and then complain when you change the implementation and
> >>> break
> >>> their code!
>
> >>> I don't know if you have seen Josh Bloch's presentation on API
> >>> design,http://www.infoq.com/presentations/effective-api-design.
> >>> One of the
> >>> rules is the element of least surprise; don't do something that will
> >>> surprise the API clients, which I think this design pattern/idiom
> >>> does. However, one of the other rules is to keep the API as small as
> >>> possible, but no smaller, which this design pattern/idiom
> >>> promotes. I
> >>> guess what you gain on the swings (no pun intended) you lose on the
> >>> roundabouts!
>
> >>> Craig.
>
> >>> On Sep 16, 2:40 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> >>> wrote:
>
> >>>> I'm interested to hear (read as it were) peoples thoughts on
> >>>> componentized designs. I bring it up because a couple of people
> >>>> have
> >>>> questioned my choice of this design strategy for the Mac Widgets
> >>>> for
> >>>> Java project (http://code.google.com/p/macwidgets/).
>
> >>>> Let me expound upon what I exactly mean by a componentized design.
> >>>> Using this type of design, the component being developed extends
> >>>> nothing but Object and thus only offers the methods that are part
> >>>> of
> >>>> it's API (no inheritance). I find this to be extremely explicit and
> >>>> very obvious. In the case of visual components (which is the
> >>>> majority
> >>>> of cases), a getComponent() method is offered, which returns a
> >>>> JComponent. Thus it's easy to change the implementation of the
> >>>> visual
> >>>> representation of the component without affecting down-stream
> >>>> developers.
>
> >>>> An example I gave in a comment on my blog (found
> >>>> herehttp://explodingpixels.wordpress.com/2008/09/14/mac-widgets-for-java-
> >>>> ...
> >>>> ) as to the peril of inheritance was JButton. JButton extends
> >>>> AbstractButton which extends JComponent. JComponent has an auto-
> >>>> scrolls property which all it's children inherit. What in the world
> >>>> does it mean for a JButton to auto-scroll?
>
> >>>> Massive inheritance trees lead to API bloat, which leads to
> >>>> confusion.
> >>>> Componentized designs force you to set your API, which in turn
> >>>> forces
> >>>> you to think about your API. The API also stays small because you
> >>>> expose only what developers need access to.
>
> >>>> Thoughts?
>
> >>>> -Ken
> >>>> P.S. You'll find that SourceList uses the compentized style design
> >>>> (see the javadoc
> >>>> herehttp://exploding-pixels.com/google_code/javadoc/com/explodingpixels/m
> >>>> ...
> >>>> ).
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
