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