The idea of a singleton is that if you only ever want one instance to exist then you can ensure this is the case. Typically I would do:
public class Singleton {
private static Singleton instance;
protected Singleton() {
// Just to stop the public default constructor being created
}
public static Singleton getInstance() {
if (Singleton.instance == null) {
Singleton.instance = new Singleton();
}
return Singleton.instance;
}
}
The reason for the getInstance method is that should we find multiple
instances are needed in the future this is easily done with code changes
in one place only. The getInstance method could change to:
public static Singleton getInstance() {
return new Singleton();
}
No other class has to know something has changed, a key part of object
orientation.
Now I hadn't realised but this actually can come with its own problems, multi-threaded applications potentially could get multiple instances, subclasses could just use the constructor, what about serialisation? There are ways to deal with this, have a look at the following link which goes into quite a lot of detail http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns.html?page=1. Read all pages, might the registry of singletons be of use here?
Michael Whapples On 01/12/10 19:03, John J. Boyer wrote:
Michael, Well, I'm still getting used to object-oriented programming. Thanks for your patience and that of others on the list. What is a singleton pattern? The snipet looks interesting. I will also check the link you give in another message for internationalization. John On Wed, Dec 01, 2010 at 02:57:06PM +0000, Michael Whapples wrote:I said I would get back with other comments. You mention there should only be one Display object per application, simple to ensure this by using a singleton pattern (there are better ways of doing it than static initialisers). The question comes though, should display belong to part of the word processing part of BrailleBlaster? I think no as there may be other user interface stuff at some point and what's going to contain the various document windows/frames/composites? As an example of part of the user interface outside the word processor part, I have a memory that the specification said when BrailleBlaster starts a dialog will be shown offering the user various options of what they can do. May be what is needed is some utilities classes, things like the Display object may be needed by user interface elements but it doesn't define what they are. On the note of defining what something is, you still seem to be missing the point of interfaces, they aren't an alternative to abstract classes, they complement them. Coming back to my person example, someone may be many things (eg. female/male, computer programmer, software developer, Braille reader, Braille writer, musician, sales person, etc) and they can be many of these, but a person only has one way of doing the task which may be common to many people but may not be defined by what they are. As an example two people may multiply numbers in the same way, regardless of if they are male or female, but someone else might multiply numbers in another way despite being the same gender as one of the two using the first system. This means we have common implementation for multiplication but that commonality does not define gender or any other role and that is when an abstract class is used. Abstract methods exist so you can depend on a method which may not be common at that point. Now just add in the single inheritance of Java with classes and I think purely using abstract classes to define roles really will hold you back. Now on a wider note, interfaces are possibly required for Java due to its static typing, a dynamic language like python would not need interfaces, but for some reason that dynamic idea hasn't really sat well with me (if you can be handed any type then how can you guarantee what you expect to find will be present). Michael Whapples On 01/12/10 03:02, John J. Boyer wrote:Where can I find a Java package for handling MDI? There is nothing obvious in SWT. One reason I was thinking of having a WindowCommon class is that an application should have only one instance of the Display widget. It could go in a static initializer in WindowCommon. It seems to me that an abstract class combines the advantages of an ordinary class and an interface. The methods defined in that clas can be called from a class which extends it, and that class can also implement methods which are only declared as in an interface. With MDI the class hierarchy becomes something like WPManager, DocumentManager, Daisy and braille wondows. John
