views:

147

answers:

5

I have a static class which I use to get access to my public properties (global for whole app) and methods which I use during application run. For example I set some property in static class and during app run time I can get value from property.

But I can create non static class with singleton pattern and use it in the same way.

Question: Which approach is correct in my case?

+3  A: 

Depends on what you're trying to achieve.

I'd go for static classes to provide utility functions in your application, and mostly avoid singletons for this type of thing. See this question for info about when to use singletons.

If your class represents some sort of entity in the system (Example: A user, a blog post, a product, a student etc.) it should not be a static class, but be instantiated every time you are logically using a separate instance of it.

Arve Systad
A: 

I think people tend to use singleton classes when they actually want a static class but need to be sure that the class is initiated with some value. But really they should both be avoided if you can.

Steve Mc
Using a singleton because a they want a "static class initiated with some values" tells me that people haven't understood the point of object orientation. The entire point of a static class is that there shouldn't be any instances of it.
Arve Systad
And that is why static is perhaps not OO but meta OO?
Caspar Kleijne
Yeah - I personally think if you want to "initiate a static class with some values" you should either be looking at an instance class or static constructors (which a lot of people don't know about).
Steve Mc
+1  A: 

My thoughts

1- Static Classes are used when there is no reason to have instances like in .net Framework Math Class.

Math class is netural to be static becuase there is no good reason to have a object of this class and then maintain the object.

2- Singleton pattern can be confused with static class concept but in singleton you get a whole object created in memory.

so it depends in the end whats your requirement.

saurabh
+3  A: 

The sample below shows that you can use interfaces with a singleton class (which is impossible with static class.)

I prefer this pattern above a large list of static methods/properties or several static classes.

Those interfaces can provide subject specific settings which can even be used as parameters to other methods or classes without that those classes need to know where the settings come from, as long as the contract is respected.

public sealed class Settings : IUserStettings, IOSettings
{
    static readonly Settings instance = new Settings();

    static Settings(){ }

    Settings(){ }

    public static Settings Instance
    {
        get { return instance; }
    }

    //-- interface implementation

    public string UserName
    {
        get { throw new NotImplementedException(); }
    }

    // ---etc...

     public string filename
    {
        get { throw new NotImplementedException(); }
    }

    //-- interface implementation
}


public interface IOSettings
{
    string disk {get;}
    string path { get; }
    string filename { get; }
}

public interface IUserStettings
{
    string UserName { get; }
    string Password { get; }
}

And this can be used in a simple manner as as:

    IOSettings iosettings = Settings.Instance as IOSettings;

    if(iosettings!=null){
        Filereader.ReadData(IOSettings iosettings);
    }

or

    IUserSettings usersettings = Settings.Instance as IUserSettings;

    if(usersettings!=null){
        UserManager.Login(IUserSettings usersettings);
    }
Caspar Kleijne
But lazy loading, caching and serializing configuration settings from an xmlDocument is also a nice practice ;)
Caspar Kleijne
+ 1 for writing all thye steps.
saurabh
+1  A: 

Seen from at OO/testability point of view neither is a particular good solution. Search SO for singleton to see arguments. That said don't use static for state only use if you need/want to write procedural code as is done with Math

Rune FS