Design question on extending a class

Question

Hi all,
I'm working on a team project where we've decided to customize many JComponents for our GUI. We're also extending the models for their respective JComponents. For example, a CustomJTextField (sublass of JTextField) has a CustomDocument (subclass of PlainDocument) as its model.
My question is this: is it a preferred OO practice (or not) to delegate the methods of CustomDocument to CustomJTextField, given that it's already understood that a CustomJTextField has a CustomDocument as its model by default. An example:
without delegation:
CustomJTextField text = new CustomJTextField();
// 1. get the model
// 2. determine if it is the type you're expecting
// 3. if so, cast it and use it
if (text.getModel() instanceof CustomDocument)
  ((CustomDocument)text.getModel()).doSomeCustomThing();
}with delegation:
CustomJTextField text = new CustomJTextField();
// 1. just ask the componet to do the work
text.doSomeCustomThing();The second form seems much cleaner, but the argument is that it would be a lot of work to delegate every method of the model to the component, and then have to maintain the delegate methods as well as the model's methods.
To me, it seems as if I'd rather have more work in one place (the subclassed JComponent) rather than having it spread all throughout the code. Also, isn't calling "getModel()" everywhere considered bad practice? Should a developer using a component even know (or care) what kind of model it has?
Even though the delegation methods seems to me that is makes the custom components easier to use, I haven't found any written examples (in books or online) of this being done anywhere. All of the examples are directly accessing the model of the component.
Any thoughts? I'm new to OO programming (as you might have guessed), so be gentle with me.
Thanks.

Answer 1

Precisely my intentions. So to reword the question -
is this a bad practice? My feeling is that a
developer using a CustomJTextField should expect some
"extra" behavior (in this case, that of a
CustomDocument) or else they'd just be using a plain
old JTextField instead. Bad assumption?Well, I guess that would depend on the custom behaviour. If the customization is to limit the field to only accept certain characters (like numbers only or a limited amount of text), then, as a Swing user, I would expect this behaviour to be handled via a custom Document. I would just say, hey, I need to put a zip code field, so I'll just make a JTextField and give it a ZipCodeDocument. getText() is going to work the same no matter what.
Another example would be if I have an IP address field. I would create an IPAddressDocument, which does validation of the data entered to prevent invalid octet values and maintain formatting. Now, getText() is going to return a string, but I might want to have a special method in the document class to return a java.net.InetAddress object as a convenience method. I suppose one could subclass JTextField as well to make IPAddressField and add a delegate method, but I'm not sure I would do that.
But I'm not clear on what these customizations are, so it's hard to say what's best for your situation. I really don't see a problem with either, though, if that's the consensus between you and your associates.
if you are writing Swing components and models,
I would expect that it follows certain patterns thatthe
rest of the Swing components useKnow of any good books, articles, etc. on this?
Everything I've read talks about extending the
JComponents, or extending the models, or extending
the renderers, etc. but always as separate exercises
and never where it's all going on at once. Even
then, the examples are usually just that, a way to
show how it works, not necessarily what the best way
to do it is.No, I don't know of any good books. They talk about extending JComponent mostly in reference to creating specialized components that are generally different from those provided. The extending models and renderers has to do with the general assumption that if you want a tree component, then JTree already gives you all you need... The customizations will be things like how do the nodes display (renderer) and where do the nodes come from (model). There's not really any link between those, though. The renderer can just be assume to be independant. Here's a node, how do I want to display it? Text, and icon, different color when selected?
>
Also, the more I read about MVC, the more confused I
am about it. Everyone seems to have different
interpretations as to the roles of each part, how each
part should interact with each other, etc. I haven't
seen anything on MVC "patterns" (as it applies to
Swing).If you haven't read this, maybe it'll shed some light...
http://java.sun.com/products/jfc/tsc/articles/getting_started/index.html