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 -~----------~----~----~----~------~----~------~--~---
