Roedy Green wrote:
Rather than creating a generalised implementation, you might just wrap
a class with a particular class built in, WITHOUT generics.
Again, because of the way polymorphism works, it's impossible to
actually provide a wrapper for (for example) TreeModel that overrides
the methods needed instead of overloading them.
It does occur to me that there is a second pattern in the Adapter family
(which includes Wrapper) that might be useful. You could define your
own, totally separate interface:
// A very simple interface
interface FooModel {
void setFooInTree( Foo f, index i );
void Foo getFooFromTree( index i );
}
And then wrap that with a TreeModel, using the Class Adapter pattern.
Kind of the reverse of what's being suggested with the Wrapper pattern.
class FooTreeModel extends DefaultTreeModel implements FooModel {
// implement FooModel here in terms of TreeModel...
}
This will still expose the TreeModel interface (which you must, to get
it to work with a JTree), but as long as your controllers, data models,
and such-like are coded to and tested against FooModel, you should
achieve reasonable separation and not be bothered by the extra methods
in FooTreeModel.
Just my 2 cents.
TreeModel really should not be used to store your app-data. Do you