Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
    
are you trying to emulate a discriminated union? –  jk. Jul 22 '13 at 6:51
add comment

3 Answers

up vote 2 down vote accepted

@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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

you can do this:

import java.util.*;
class Super {
    Super() {
        subclasses.add(getClass());
    }
    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();
        System.out.println(Super.subclasses);
    }
}
share|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
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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