Java-Gaming.org Java4K winners: [ by our judges | by the community ]         
Featured games (67)
games approved by the League of Dukes 		Games in Showcase (∞)
games submitted by our members



News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Java-Gaming.org > Game Development > Newbie & Debugging Questions > Singleton vs. class with only static methods
Pages: [1]
  Print  
  Singleton vs. class with only static methods  (Read 3790 times)
0 Members and 2 Guests are viewing this topic.
Offline erikd

JGO Kernel
*****

Posts: 2561
Medals: 7


Maximumisness
« on: 2003-10-22 02:52:56 »
Hi there,

Having read about the Singleton, I'm wondering: Why a Singleton with the private constructor stuff and all? Isn't it easier to create a class with static methods and a static initializer, something for example like:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
public class Test {
  private static String value;

  static {
    value = "test";
  }
  
  public static String getValue() {
    return value;
  }
}


Isn't that easier than the java singleton stuff?
What great advantage about the singleton am I missing?

Greetings,
Erik
http://www.gagaplay.com
Offline Markus_Persson

JGO Kernel
*****

Posts: 2092
Medals: 10


Mojang Specifications
« Reply #1 on: 2003-10-22 03:13:15 »
singletons are just "prettier", as it's basically just a class with no public constructor and a public factory method.
You can even hide the fact it is a singleton from the user of the class.. only the class itself needs to know how it works. That means you can refactor it into a non-singleton class in the future without having to break other code.


/ Markus "Wishing all constructors were private" Persson
Wink
Play Minecraft!
Offline erikd

JGO Kernel
*****

Posts: 2561
Medals: 7


Maximumisness
« Reply #2 on: 2003-10-22 03:29:45 »
I don't think a private constructor is that pretty  :-/
Creating a static class instead of forced single instance  seems more natural to me.

When you have to refactor the singleton to a non-singleton, you probably made a design error, but hey everybody makes them (I should know  Wink)
However, I suspect when you do refactor your singleton to a non-singleton, chances are than you break code that relies on the singleton being in fact a singleton. And why creating a singleton in the first place when you can't rely on the singleton being in fact a singleton?

Erik
http://www.gagaplay.com
Games published by our own members! Go get 'em!
Offline cfmdobbie

JGO Wizard
****

Posts: 1257


Who, me?
« Reply #3 on: 2003-10-22 04:15:09 »
One useful point about them is that they are still normal objects.  You can obtain a reference to a singleton and pass it to someone else, and they can use it as any other object.  If you changed it to an all-static interface this just wouldn't be possible.
Hellomynameis Charlie Dobbie.
Offline erikd

JGO Kernel
*****

Posts: 2561
Medals: 7


Maximumisness
« Reply #4 on: 2003-10-22 06:05:27 »
With an all static class, you would never have to pass a reference to it to another object. I can't think of a reason why you would have to be able to in a singleton. I mean there's always just one and every object can get its reference using the method in the singleton class that is meant to provide that reference.
I suppose I'm still missing the clue Huh
http://www.gagaplay.com
Offline cfmdobbie

JGO Wizard
****

Posts: 1257


Who, me?
« Reply #5 on: 2003-10-22 06:18:33 »
But how about if the specific object type isn't something that the target code needs to know?  You can still manipulate the object-type singleton via an interface, but with the static-type singleton the target code would have to refer directly to the particular implementation.

EDIT: This really needs an example to be perfectly clear!  How about storing a singleton object in a JNDI repository?  Or implementing a JDBC DataSource as a singleton (for whatever reason)?
Hellomynameis Charlie Dobbie.
Offline erikd

JGO Kernel
*****

Posts: 2561
Medals: 7


Maximumisness
« Reply #6 on: 2003-10-22 06:48:43 »
Ah yes, I suppose you'll have a problem when you want the all static class to implement an interface which would be no problem for the singleton.
http://www.gagaplay.com
Offline tortoise

Full Member
**

Posts: 230


<3 Shmups
« Reply #7 on: 2003-10-22 09:44:28 »
Many things expect objects, not classes. If you just want one of those objects, a singleton's a good way to do it.

In my current program I have a toolbox window. I only want one. But it still has to be an instance of JInternalFrame. The static approach wouldn't work.
Offline Mojomonkey

JGO Ninja
***

Posts: 540
Medals: 3


ooh ooh eee eeee
« Reply #8 on: 2003-10-22 09:50:25 »
I try to follow this rule (whether or not it's a good rule is debatable).

If I have something that I'll only one a single instance of in a JVM:

1. If it maintains state, singleton. Otherwise, static.
Don't send a man to do a monkey's work.
Offline Markus_Persson

JGO Kernel
*****

Posts: 2092
Medals: 10


Mojang Specifications
« Reply #9 on: 2003-10-22 10:40:30 »
Good rule, imo. *wishing there was a thumbs-up emoticon*
Play Minecraft!
Games published by our own members! Go get 'em!
Offline cfmdobbie

JGO Wizard
****

Posts: 1257


Who, me?
« Reply #10 on: 2003-10-22 12:54:02 »
Quote
Good rule, imo. *wishing there was a thumbs-up emoticon*


/me hands Markus a

Grin
Hellomynameis Charlie Dobbie.
Offline Markus_Persson

JGO Kernel
*****

Posts: 2092
Medals: 10


Mojang Specifications
« Reply #11 on: 2003-10-22 13:20:14 »
Ooohh. How/where did you find that? =D
Play Minecraft!
Offline cfmdobbie

JGO Wizard
****

Posts: 1257


Who, me?
« Reply #12 on: 2003-10-22 13:37:04 »
It's one of the options for a message logo (see above) so it's already on the JGO server.  I just copied the url and chucked it between a [ img ] [ / img ] pair.  This is also the only way of getting the animated laugh smiley: .

I think I've been here too long...
Hellomynameis Charlie Dobbie.
Offline Preston

Sr. Member
**

Posts: 346
Medals: 2
« Reply #13 on: 2003-10-22 13:39:34 »
Quote

If I have something that I'll only one a single instance of in a JVM:

1. If it maintains state, singleton. Otherwise, static.

This is a good rule. I used singletons for a quite large C++ project some time ago and we used practically the same rule and it went well. :-)

Whenever a (single instanced) class has got some kind of states, so that the order of when it is beeing created could matter, a singleton is much safer than a static only class.

For a "function"-like class (like Math.sin() etc) pure static classes makes perfect sense. :-)
Memento mori.
Pages: [1]
  Print  
 
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.16 | SMF © 2011, Simple Machines Valid XHTML 1.0! Valid CSS!
Page created in 0.122 seconds with 19 queries.