I appreciate the constructive criticism and will look into making things more generalized … what I believe you are saying is I should just have a planet class and build on that rather have an earth class and a venus class ect… What do you mean by singleton?? could you give an example??
Yes, one planet class, but earth = new Planet("Earth"); The only thing different from earth to venus are "properties" (ie: what it is) not functions (ie: how to do it). One class for how to do it (ie: similar functions), but many "instances" (ie: "new Planet(…)") for each set of "what it is".
I think you understand what I meant before, just repeating (I like to hear myself type :D).
A singleton means that only ONE single instance of a class can exist. This is useful because if there is always only one class I should be able to get that instance of the class from anywhere in my code easily, there is only one ;). So lets say I had one main class that called all the other things. I might call this MyManager, and I might want other classes to be able to find it. I will show you how to make a simple Singleton below:
public class MyManager{
private static MyManager myManagerSingleton = null;
public MyManager(){
....
}
public static MyManager singleton(){
if( myManagerSingleton == null){
myManagerSingleton = new MyManager();
}
return myManagerSingleton;
}
}
Now, if I want to create a MyManager, I must call: MyManager.singleton(); And it will be created if one doesn't exist, if it DOES exist it will return the original one created, I don't care if it exists or must be created, I just want it!!!
This is useful because if MyManager had the HashMap of all the objects I could do this:
MyManager.singleton().getPlanetHashMap().get("earth");
This way I don't need need to pash 100 hashmaps around and not even pass the class MyManager!!! I can just reference the MyManager which holds all 100, then get the correct data from there :).... If you don't want to make a "get___" for each HashMap, you can just make each HashMap public and write:
MyManager.singleton().planetHashMap.get("earth");
I did try to summarize the idea of a singleton, but that should be enough info, if not you can google more indepth discussions, as well as better coding for singletons. I use something similar, but there are better (more rugged/stable) sets of code out there.
I found it ingenius when I first saw it too. That is why I enjoy working with others on projects at work so I can see how others thhink and what do. I don't suggest starting from scratch unless it's a serious program just keep making your coool program.
Btw I also am looking through the tutorials and having fun with it. Trying to make a first person shooter right now. I am stuck on getting models, importing, animating. I think I bit off more then I can chew lol. Especially since it's for fun.
Btw I am happy you enjoyed the info.
I would like to add a few things about singletons.
You should ALWAYS make your constructor for a singleton class private so that a user does not inadvertently call the constructor instead of calling the method singleton().
Also a slightly better implementation to prevent race conditions. Note the use of final and private.
public class MyManager {
private static final MyManager instance = new MyManager();
private MyManager() {
....
}
public static MyManager singleton() {
return instance;
}
}
BTW, the standard method name for getting the singleton instance is getInstance() but it's your choice.
In effective Java, Joshua Bloch discusses using the enum pattern as the desirable approach.
Thus the code would be:
public enum MyManager{
singleton;
public void addPlanet(...){...}
}
Now one must only do: "MyManager.singleton.addPlanet("earth")"....
Enum is better as:
1). concise.
2). provides serialization machinery for free.
3). provides ironclad gaurantee against multiple instantiation, even in the face of sophisticated serialization or reflection attacks.
See Page 18 of Effective Java Programming (Second Edition).
The method I programmed before (yes, private and final are good to add of course) was simply the best way of describing the design pattern. Imo either way is fine unless they are scared of "hacking" or someone "breaking" their code (ie: are they even going to make it a library?).