Почему «readonly» имеет важное значение в следующей реализации Singleton?

Question

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

• Его статический, только один экземпляр будет существовать.
• Значение can not change, так как оно не имеет сеттера.
• Его запечатанный класс, не может быть подклассом.

Пожалуйста, помогите мне исправить свое понимание концепций здесь.

Answer 1

Потому что, если поле не было отмечено readonly, оно может быть изменено в классе Singleton. Конечно, он по-прежнему не может быть изменен внешним миром, но синглтон действительно не является ничем, если в течение жизни вашей программы есть более одного экземпляра, а спецификатор readonly обеспечивает семантику, которую вы хотите в одноэлементный класс.

EDIT в ответ на:

1. его статическую, только один экземпляр будет существовать.
2. Значение can not change, так как оно не имеет сеттера.

Статические переменные, безусловно, могут быть установлены для ссылки на разные объекты во время выполнения. Значение может измениться, если только внутри класса из-за его приватности. Если класс был реализован таким образом, что поле было назначено только один раз, это не было бы проблемой на практике. Однако, поскольку предполагаемое намерение состоит в том, что экземпляр singleton никогда не изменится, модификатор readonly гарантирует эти семантики вне конструктора. Это не essential, потому что клиенты класса не могут изменить ссылку, но это предпочтительнее, потому что это: а) делает цель кода чистой и b) препятствует изменению ссылки даже внутри класса.

Answer 2

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

BTW Я думаю, что лучше использовать синглтон с двойной проверки блокировки:

public sealed class Singleton 
{ 
    private Singleton() 
    { 
     // Initialize here 
    } 

    private static volatile Singleton _singletonInstance; 

    private static readonly Object syncRoot = new Object(); 

    public static Singleton Instance 
    { 
     get 
     { 
      if(_singletonInstance == null) 
      { 
      lock(syncRoot)) 
      { 
       if(_singletonInstance == null) 
       { 
        _singletonInstance = new Singleton(); 
       } 
      } 
      } 

      return _singletonInstance; 
     }   
    } 
} 

Answer 3

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

Answer 4

Я удалил readonly в классе, потому что хотел сделать OneAtaTimeleton (вместо Singleton).

Почему? Ну, класс содержал некоторую конфигурацию, которую я хотел, чтобы пользователь (администратор) мог меняться во время работы приложения.Таким образом, я добавил статический метод Reload() к классу, который имеет:

instance = new Configuration(); 

, следовательно, необходимость удаления ЧТЕНИЯ.

Закрытая версия конструктора загружает конфигурацию (через нестатический метод).