Is a static class appropriate when state is immutable?

Question

Let's say I have a simple class called WebsterDictionary that has a function that can take a word and return its definition. Perhaps there is another function that can take a definition and return a word. The class is used all the time by many clients.

To facilitate the lookups, the class contains a member variable that is an in-memory Dictionary which stores the words and their associated definitions. Assume the Dictionary can never change once it is initialized -- it's constant and would not vary across instances.

Is this a good candidate for static class? I've been reading that static classes should be stateless...but this class has state (the in-memory dictionary) right?

EDIT: Also, if this does become a static class, when do I initialize the Dictionary since there would no longer be a constructor? Do I do check to see if the reference to the Dictionary is null every time one of the static methods is called?

Thanks.

Answer 1

A static class is suitable when the functionality doesn't need to be replaceable (e.g. for tests). If you might want to use a stub or a mock, you should create an appropriate interface, and then implement it with a singleton.

Answer 2

To expand upon others' answers, a static class or singleton is useful when you need to have only one instance of a class. This is much easier to accomplish when the data is immutable. Thus, there is a possibility that a static class is what you want to use for this. But it's not necessarily the case that it's automatically what you want to use.

My advice is to ask yourself one question: will the world come crashing down if I instantiate more than one of these objects? If so, use a singleton or static class. Otherwise, use a regular class.

Answer 3

A static class might be what you want here (see other answers). But don't make the mistake of calling your dictionary "immutable".

Immutable does not mean "can never change at runtime" in the sense that you used the phrase, because your Dictionary actually does change at runtime; after you must create it you must also add the items. Even at this point you may intend that it never change again, but it is possible to change it. Your intent is not enforced anywhere.

A true immutable object cannot change after creation, no matter how much you try. Instead, when you need a variation of the object you must create a new instance with the desired attributes.

You can think of a static class in one sense as having exactly one instance. That's probably not the best choice for a pattern where you depend on creating new instances for each state change.

Answer 4

You could either go Singleton or a Static class. I would probably go with a Singleton but I think it's mostly a preference issue in this particular situation.

Answer 5

A static class is appropriate when only one "instance" should ever exist, in which case the Singleton pattern may or may not be more appropriate (depending on the details). For an immutable object that you'll need multiple instances of, of course a static class is inappropriate.

Answer 6

What you are looking for might be Singleton?

It is not necessary that static class need not have state (it can have static members as part of it, which can be part of its state).

Answer 7

It sounds very much like you're describing the Monostate pattern: you would like the same WebsterDictionary to be shared by everyone. It just so happens that the WebsterDictionary is also immutable, but that is an orthogonal concern: just make it impossible to update (for example, by using a read-only wrapper).

Answer 8

As you said the class is holding some form of global state, even if it is read only. Going the Singleton approach makes it really clear it is holding data.

If you use dependency injection you can have it inject singleton instances, instead of making all the classes have code that gets you the instance. This means the other classes won't be tied to the Singleton approach, and if you can more easily replace it when testing (combined with an interface to enable replace with test mocks).