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