Singleton vs. class with only static methods

Newbie & Debugging Questions
#1

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:


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

#2

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:

#3

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 ;))
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

#4

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.

#5

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 ???

#6

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)?

#7

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.

#8

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.

#9

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.
#10

Good rule, imo. wishing there was a thumbs-up emoticon

#11

[quote]Good rule, imo. wishing there was a thumbs-up emoticon
[/quote]
/me hands Markus a

;D

#12

Ooohh. How/where did you find that? =D

#13

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…

#14

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. :slight_smile:

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. :slight_smile:

#15

Almost a decade has passed since the previous response and the use of dependency injection is common now. Often times the injected instance is a stateless Singleton. However, a class with static methods would not lend itself to injection. Note that this predicament is essentially the same as the one referred to by tortoise in an earlier response.

#16

Just WHY did you necro an almost 10 year old thread?!

WHY!!!

#17

He DANCES ON THE GRAVE!

Cas :slight_smile:

#18

Since “singleton” is the username I was assuming this was a pro-wrestling match. I feel so let down.

#19

He only cam here to do EXACTLY THAT…

#20

Since this thread had already been necro’d and I read the OP…

public class Test {
  private static String value;

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

Wont this code give a compile error? I’ve never seen code that just says “static{}” and does stuff within that.