Hi Craig, Fair enough...the tooling point is a good one. I can only think of a work-around (maybe an adapter class) to the issue you raise.
-Ken On Sep 17, 2:21 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Hi Ken, > > Yes, but as someone pointed out in the comments on your blog, the > improved API has come at the expense of tooling. Since the class is no > longer a Swing component, Swing GUI builders like Matisse can no > longer use them. As I said in my original post, what you gain on the > swings you lose on the roundabouts! > > Craig > > On Sep 17, 11:59 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > wrote: > > > Hi Craig, > > > At some level you have to expose the actual visual components, so yes, > > there is that constant. What is much cleaner though, is the > > presentation of the API when it is isolated. When you extend > > JComponent, your API is muddled with that of JComponent. > > > I find that componentized design makes it much harder for developers > > to incorrectly use your component. Developers are forced to request an > > enhancement rather than work around an issue, which lets the component > > developer fully evaluate the ramifications of the enhancement. This > > prevents the oft encountered unexpected usage problem. > > > If Swing were redesigned, I suspect they would avoid the deep > > hierarchies that have become so unwieldy. > > > -Ken > > > On Sep 17, 3:31 am, "[EMAIL PROTECTED]" > > > <[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 -~----------~----~----~----~------~----~------~--~---
