Abstract static?

Question

Hi. I have this question. I have a class, say "City", which has a static method, City.getList(), which returns an Object[] with all the available cities. I also have a Class "State" , which also has a .getList() method which returns an Object[] with all available states.
I made a JPanel with a Jtextfield and a JList. The textfield, when the user has entered 3 or more characters, does a .getList(String filter) that loads the JList with the data from the database, so I can make a quick search.
The problem is that I want to make it generic, so I made an interface "ProvidesAList" with the methods getList() and getList(String filter). So when I call the constructor for this JPanel, I have to provide it with the kind of "thing" i want to be able to search. That is, if I want to search cities, I call the constructor referencing a City object. But the problem is that I don't want to provide an object, but just a class name, as in, for example, new SearchBox(Class.forName("City"));
What I did was, declare the constructor as
SearchBox(ProvidesAList thing)
and then calling it as
new SearchBox(new City());
it works because City implements ProvidesAList.
My problem is, I don't want to create an instance of city, or state, or whatever, every time I want to make a quick search. Also I use the .getList() methods elsewhere in the code, and I don't want to create an object jus to use that methods. So I want to define the methods as static, so all I have to do is ClassName.getList();
But I can't define the methods in ProvidesAList as static (because Interfaces cannot have static methods).
How can I have this? I wouldn't want to make parent class with the static methods because it would be nasty to have a "ProvidesAList" class and City extends ProvidesAList, State extends ProvidesAList, and Customer extends ProvidesAList.

Answer 1

Well, if the City and State classes have things going on other than merely providing these lists, then yeah, you should preserve their identities rather than combining them. But I still think you should write a class for AutoCompleteModel and consider your city and state data separate from those classes. Why hard code a list of cities when the requirements could change tomorrow?
Also, the City and State model is going to collapse if someone in Japan ever tries to use your program. So the model I would suggest at this point is this:
class Area
Has a String member for its name and a single Area member for a parent area (for example, if this instance represents a city then the parent instance is a state... if the instance is a state the parent represents the U.S.) and an Area[] for children areas (if this instance is a state, its children are cities). Methods for traversing parents and children make this class a kind of node that can be used to build arbitrary hierarchies. Maybe has a String member for indicating its geopolitical classification ("city", "state", "ward", "principality"...)
class AutoCompleteModel
Has a String[] for the data to be matched against, and methods for matching. Can be instantiated from an array and/or file, InputStream, etc.
Isn't that solution both more conceptually simple (albeit not coding-simple) and comprehensive?
If you do not want to spend the extra time to program a truly GOOD solution, because for example this is just for some lame homework project or something, then my answer changes to:
Just get over the peeve about instantiating objects and use the solution you have already come up with. There is no need for multiple instances - just keep a reference to the instance you already made.
Rule of thumb: if the way the language is structured conflicts with your design approach, there is a high chance that your design approach is not so good anyway.
Not to be all high and mighty or anything. Actually I ran into this exact issue a few months ago (a couple months after I started Java), except that there was no question of pre-set data in my case. The solution I settled on was pretty much what I say above.
Drake