For the GUI of a program, I want it to list several items, all of which are, from a programming side, just subclasses. They can add one of these items to a list. I don't want to hard-code which subclasses there are. What would be the best way to allow the GUI to know about the subclasses, only having the base class to refer to?


@Andrew Timson (+1) makes a superb point about the use of reflection (if possible) and using an interface.

From an Object Oriented Design point of view, Interface's are going to be a much nicer way to go - unless of course there is enough logic in common/inherited to warrant subclassing. This could be argued as part of the "Dependency Inversion Principle" at work; "Depend upon Abstractions. Do not depend upon concretions.". You're already leaning towards quite a clean solution that adheres to this by avoiding the hard coding though, so nice one!

In addition to that, Reflection could be the way to go. There's some more information on when reflection should be used over here, on StackOverflow

Other than that, you could use something like an adapted Observer Pattern and have each new instance of a given sub-class "register" itself upon initialisation. So there is an object you can query to get all of the objects in question; you could make this a Singleton to ensure it's always accessible throughout the lifecycle of the application - and to make sure there is only ever one object to query.

That's not the neatest solution, but it is another one that could work.

| improve this answer | |
  • For singletons created statically, this isn't a problem, but registering on instantiation could mean you'll miss some subclasses (if they haven't been used.) – Joshua Goldberg Sep 4 '14 at 19:15

First off: I think in this case, rather than populating the list with a class/subclasses of it, using some sort of interface may be the more appropriate design.

The best approach is probably going to depend on your language. If it supports reflection (like C# or Java), you may be able to look for other classes that subclass/implement your interface.

If it doesn't - or if you want a simpler solution - you can simply keep the list of available types in some sort of configuration file/table that gets read in at runtime.

| improve this answer | |

you can do this:

import java.util.*;
class Super {
    Super() {
    static List<Object> subclasses=new LinkedList<Object>();
class Sub1 extends Super {
class Sub2 extends Super {
public class P205597 {
    public static void main(String[] args) {
        new Sub1();
        new Sub2();
| improve this answer | |
  • 1
    He wants a list of classes, not objects. Also, this code will prevent all objects from being garbage collected - massive memory leak. – Michael Borgwardt Jul 22 '13 at 7:08
  • He is keeping the Class objects not the instances of the subclasses so there should be no problem with GC imho. However I would change the collection to Set instead of List to avoid duplicities. – Honza Brabec Jul 22 '13 at 12:25
  • yes, a set would be better since it's a class. i used list because he said list. – Ray Tayek Jul 23 '13 at 22:28
  • In a more realistic context, where you wouldn't want main of a large system to contain a list of subclasses relevant to a particular subsytem, this will not get the full list of classes until an instance of each one has been instantiated (or could be never, if some don't get used in a particular run, depending on user actions, e.g.) – Joshua Goldberg Sep 4 '14 at 19:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.