Статический класс против экземпляра класса

Question

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

Мои мысли

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

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

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

поэтому в конечном итоге это зависит от ваших требований.

Answer 5

При взгляде на ОО/тестопригодность точка зрения ни является частным хорошим решением. Найдите SO для singleton, чтобы увидеть аргументы. При этом не используйте статические для использования только в том случае, если вам нужно/нужно написать процедурный код, как это делается с помощью Math