Question

I wanted to know if this was good practice or not, I am not really sure if this class should be static class or not?

   public class SettingsHelper
{
    public static readonly string MinVal= "MinVal";
    public static readonly string MinPartners = "MinPartners";

    public static IDictionary<string, string> GetSettings(string jsonsettings)
    {
        var settings = JsonConvert.DeserializeObject<Dictionary<string, string>>(jsonsettings);
        return settings;
    }


    public string SettingsToJson(IDictionary<string, string> settings)
    {
        var jsonsettings = JsonConvert.SerializeObject(settings);
        return jsonsettings;
    }


    public static decimal GetMinPartners(string jsonsettings)
    {
        var settings = GetSettings(jsonsettings);

        string partners;
        settings.TryGetValue(MinPartners, out partners);

        return decimal.Parse(partners);
    }

    public static int GetMinValue(string jsonsettings)
    {
        var settings = GetSettings(jsonsettings);

        string pival;
        settings.TryGetValue(MinVal, out pival);

        return int.Parse(pival);
    }

}

I want to include methods such as, update partners, add partners etc…

Answer 1

I assume that with ‘static class’ you mean a class with only static methods.

There are very few good reasons for static methods. Maybe if you need to implement a real Singleton (something that will try to kill you if it exists twice). But this doesn’t seem to be the case here.

There are some acceptable reasons for static methods like

• there is no state
• alternative implementations really don’t make much sense

These might apply in your case. => so the design might be ok.

Probably a proper class (or possibly a class per method) might be even better.

Clients of your methods/classes would get an instance in the constructor, possibly with a default constructor which creates the normal instances.

Here is what you would gain:

• When testing clients you can easily provide canned answers with mocks, you don’t need to use valid json strings. In case of clients that don’t create these Strings themselves this prevents tons of failures unrelated to the actual class under test when the structure of your json string changes.

• When some day some of this information comes from xml, a database or divination, especially when this distinction is made by client and not be type of information, it will be easy to switch.