Статический класс против Экземпляра класса - PullRequest
3 голосов
/ 11 сентября 2010

У меня есть статический класс, который я использую, чтобы получить доступ к своим общедоступным свойствам (глобальным для всего приложения) и методам, которые я использую во время работы приложения. Например, я установил некоторое свойство в статическом классе, и во время выполнения приложения я могу получить значение из свойства.

Но я могу создать нестатический класс с одноэлементным шаблоном и использовать его таким же образом.

Вопрос: Какой подход является правильным в моем случае?

Ответы [ 5 ]

3 голосов
/ 11 сентября 2010

Пример ниже показывает, что вы можете использовать интерфейсы с одноэлементным классом (что невозможно со статическим классом.)

Я предпочитаю этот шаблон выше большого списка статических методов / свойств или нескольких статических классов.

Эти интерфейсы могут предоставлять специфические для субъекта настройки, которые могут даже использоваться в качестве параметров для других методов или классов без того, чтобы эти классы знали, откуда поступают настройки, при условии соблюдения контракта.

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; }
}

И это можно использовать простым способом, как:

    IOSettings iosettings = Settings.Instance as IOSettings;

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

или

    IUserSettings usersettings = Settings.Instance as IUserSettings;

    if(usersettings!=null){
        UserManager.Login(IUserSettings usersettings);
    }
3 голосов
/ 11 сентября 2010

Зависит от того, чего вы пытаетесь достичь.

Я бы пошел на статические классы для предоставления служебных функций в вашем приложении, и в основном избегал бы одиночных вычислений для этого типа вещей.См. этот вопрос для получения информации о том, когда использовать синглтоны.

Если ваш класс представляет какую-то сущность в системе (Пример: пользователь, запись в блоге, продукт, студент и т. Д.).) он не должен быть статическим классом, а должен создаваться каждый раз, когда вы логически используете его отдельный экземпляр.

1 голос
/ 11 сентября 2010

Если смотреть с точки зрения OO / тестируемости, ни одно из них не является хорошим решением.Поиск SO для синглтона, чтобы увидеть аргументы.Тем не менее, не используйте static для использования только состояния, если вам нужно / нужно написать процедурный код, как это делается с Math

1 голос
/ 11 сентября 2010

Мои мысли

1- Статические классы используются, когда нет причин иметь экземпляры, как в .net Framework Math Class.

Класс Math является естественным, чтобы быть статическим, потому что нетхорошая причина иметь объект этого класса и затем поддерживать его.

2 - Шаблон синглтона можно спутать с концепцией статического класса, но в синглтоне вы получаете целый объект, созданный в памяти.

так что в конце концов, каково ваше требование.

0 голосов
/ 11 сентября 2010

Я думаю, что люди склонны использовать одноэлементные классы, когда им действительно нужен статический класс, но нужно быть уверенным, что класс инициируется с каким-то значением. Но на самом деле их следует избегать, если вы можете.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...