Hi Alexey, I agree with what you are saying if you were going to derive your class from something other than JComponent, but at the end of the day JComponent derives from java.awt.Container, so you can still aggregate the components that you want to use (JButton, JLabel, JList etc.) inside your custom widget class and just use the JComponent parent to contain them. As Ken pointed out, this pollutes your own API with that of the JComponent class hierarchy, but it doesn't expose the aggregated components any more than Ken's componentized design does.
Just to make my position clear, I am not criticizing Ken for his decision. It's just that, as someone who writes API for a living (and has learned many lessons the hard way), I'm interested in the pros and cons of the approach.. Craig On Sep 17, 8:16 pm, Alexey Zinger <[EMAIL PROTECTED]> wrote: > --- On Wed, 9/17/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> > > Subject: [The Java Posse] Re: Componentized Designs > > To: "The Java Posse" <[email protected]> > > Date: Wednesday, September 17, 2008, 3:31 AM > > 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? > > Actually, no. The difference is in how the client code sees it. Consider > the following: > > public class MyButton extends JButton > { > ... > > } > > public class MyButtonComponent implements MyComponentInterface > { > public JComponent getComponent() > { > // returns JButton... maybe > } > > } > > If I'm working against MyButton, there is a whole set of API I am guaranteed > of having access to, whereas if I'm working against MyButtonComponent, I am > given just the API the author of MyButtonComponent and its framework deemed > appropriate in that context. > > Now look what happens if the widget I'm working with suddenly needs to be > changed (either at compile time or maybe even at runtime). In the case of > MyButton, the onus is on whoever's doing the painting and layout. Maybe it's > MyButton class itself, or maybe (more along the Swing philosophy) some > implementation of ButtonUI. > > But if I'm working against MyButtonComponent, I can simply switch delegation > logic between whatever kind of widget seems appropriate at the time. Now, > this isn't without problems of course. If we're plugging this into the > existing Swing world, we have to be very very cautious of event handling. > Since we no longer allow the client to register their UI-specific event > listeners (such as ActionEventListener), we have to build in a level of > indirection and expose appropriate events from whatever widget delegate we're > using at the time. But this isn't much different of a problem than what we'd > potentially be faced with if we were building a complex widget by inheriting > off a composite widget class, such as JPanel that's allowed to contain > whatever combination of widgets we really want to do the painting. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
