Question

I would like to do something like this:

public class Foo {
    // Probably really a Guid, but I'm using a string here for simplicity's sake.
    string Id { get; set; }

    int Data { get; set; }

    public Foo (int data) {
        ...
    }

    ...
}

public static class FooManager {
    Dictionary<string, Foo> foos = new Dictionary<string, Foo> ();

    public static Foo Get (string id) {
        return foos [id];
    }

    public static Foo Add (int data) {
        Foo foo = new Foo (data);
        foos.Add (foo.Id, foo);

        return foo;
    }

    public static bool Remove (string id) {
        return foos.Remove (id);
    }

    ...

    // Other members, perhaps events for when Foos are added or removed, etc.
}

This would allow me to manage the global collection of Foos from anywhere. However, I’ve been told that static classes should always be stateless–you shouldn’t use them to store global data. Global data in general seems to be frowned upon. If I shouldn’t use a static class, what is the right way to approach this problem?

Note: I did find a similar question, but the answer given doesn’t really apply in my case.

Answer 1

Who stays that static classes should be stateless? Static means stated.

Just know how static classes work in the CLR:

• You can’t control the time when static constructors are called.
• Static classes have a separate state for each calling program.

Also be aware of concurrency issues.

As a side note, it amazes me how often people say “Don’t use X.” It would be like someone walking into your toolshed and pointing to half a dozen tools and saying, “Those tools are bad practice.” It doesn’t make sense.