Design Question - Class Must Implement Interface

Question

I'm not sure how to describe this in summary, really. I'd say that I sort of want multiple inheritance, but I don't want to be shot. :-P So let me describe the situation:
I have an interface, DataEditingComponent<T>. The idea is that anything implementing the interface is capable of allowing the user to edit an object of type T. For example, a DataEditingComponent<Integer> would allow the user to input an integer. A DataEditingComponent<Map<SomeObj,Integer>> might represent an object capable of editing a table describing the number of instances of SomeObj. You get the idea. DataEditingComponent<T> describes three methods: getEditingData():T, setEditingData(T):void, and getDefaultEditingData():T. I'm assuming you can guess what those do.
Well, the practical application of this interface is in the use of a Swing application. It provides a very clean and standardized way of adjusting the contents of components which edit data. Obviously, a JTextField would work about as well as a DataEditingComponent<String>, but for more complicated components (DataEditingComponent<GameWorldMap>, for instance), the standardized interface is very helpful.
Since in practice everything that ever implements DataEditingComponent<T> extends JComponent, it would be nice to declare this as a requirement somehow. However, given that JComponent is extended into a number of various subclasses, I can't just go making DataEditingComponent<T> an abstract subclass.
So far, the only conclusion I've reached is that I can take each and every JComponent subclass and extend it into an abstract subclass which implements DataEditingComponent<T>... but that's very ugly and quickly leads to other problems. And presently, I'm left casting things from one to the other, with which I am also not happy.
So... any way out of this? Have I done something wrong design-wise? Or am I just stuck in a language limitation?
Thanks for reading!

Answer 1

I'm not sure how to describe this in summary, really.
I'd say that I sort of want multiple inheritance,
but I don't want to be shot. :-P So let me
describe the situation:
I have an interface, DataEditingComponent<T>. The
idea is that anything implementing the interface is
capable of allowing the user to edit an object of
type T. For example, a DataEditingComponent<Integer>
would allow the user to input an integer. A
DataEditingComponent<Map<SomeObj,Integer>> might
represent an object capable of editing a table
describing the number of instances of SomeObj. You
get the idea. DataEditingComponent<T> describes
three methods: getEditingData():T,
setEditingData(T):void, and
getDefaultEditingData():T. I'm assuming you can
guess what those do.
Well, the practical application of this interface is
in the use of a Swing application. It provides a
very clean and standardized way of adjusting the
contents of components which edit data. Obviously, a
JTextField would work about as well as a
DataEditingComponent<String>, but for more
complicated components
(DataEditingComponent<GameWorldMap>, for instance),
the standardized interface is very helpful.
Since in practice everything that ever implements
DataEditingComponent<T> extends JComponent, it would
be nice to declare this as a requirement somehow.
However, given that JComponent is extended into a
number of various subclasses, I can't just go making
DataEditingComponent<T> an abstract subclass.
So far, the only conclusion I've reached is that I
can take each and every JComponent subclass and
extend it into an abstract subclass which implements
DataEditingComponent<T>... but that's very ugly and
quickly leads to other problems. And presently, I'm
left casting things from one to the other, with which
I am also not happy.
So... any way out of this? Have I done something
wrong design-wise? Or am I just stuck in a language
limitation?Hmm. The component is part of the view. The data is part of the model. Putting them together seems to go against the whole Model-View-Controller concept. You may want to have a look at how Swing separates the editing from the rendering from the model for complicated widgets such as JTable. The editors hava methods such as getEditorComponent() which returns the Component used to edit the data. Everywhere you are currently adding DataEditingComponent instances to your GUI, you can instead call a getDataEditingComponent() method, which can require that the returned object is a JComponent.