Hi Joshua, Even if you sub-classed JComponent, couldn't you achieve the same result by making your class final?
Craig On Sep 17, 4:34 pm, 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 -~----------~----~----~----~------~----~------~--~---
