It's not necessarily any better from an implementation point of view. You can often do the same thing with a static class as you can with a singleton.
The big benefit comes if you need to change from singleton/static to different instances for each invocation. If you have followed the static class approach you have static method calls all through your code that you will need to change if the class now needs to be non-static. If you have followed the singleton approach, you only need to change the line of code that retrieves the instance inside the singleton. That's a pretty big benefit IMO. To get back to where we started all this, the original statement that brought all this up was your suggestion that Foo.someMethod() was identical to Foo.getInstance().someMethod() Whether one is better than another is something that can be debated to death, and often is on Java mailing lists, but hopefully you'll at least agree that they are indeed doing different things. Spike On 10/29/05, JesterXL <[EMAIL PROTECTED]> wrote: > > I would have 20 static classes, not 20 if/then/switch statements. You'd > have that same if/then statement in the getInstance() function, though, to > know which formatter to return. > > Again, I'm having a hard time seeing why getInstance is more appopriate > than > just making static classes, and how this applys to the Singleton pattern. > > > _______________________________________________ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
