Is it bad practice to have state in a static class?

Posted by Matthew on Stack Overflow See other posts from Stack Overflow or by Matthew
Published on 2010-05-02T16:24:15Z Indexed on 2010/05/02 16:27 UTC
Read the original article Hit count: 294

Filed under:
|
|
|

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.

© Stack Overflow or respective owner

Related posts about c#

Related posts about static