Статический шаблон инициализации

Question

Каков наилучший способ инициализации статических полей с помощью статического метода init и после этого убедитесь, что метод никогда не вызывается снова? (не более одного раза в течение срока действия программы)

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

class Entity 
{ 
    static Manager manager; 
    static bool isInitialized; 

    public static void Initialize(Manager manager) 
    { 
     if (isInitialized) 
      throw Exception("Class Entity already initialized." 
       + "Do not call Entity.Initialize() twice."); 
     isInitialized = true; 
     Entity.manager = manager; 

    } 
} 

Answer 1

что является лучшим способом для инициализации статических полей с помощью статического метода инициализации, а затем убедитесь, что метод никогда не вызывается снова?

Действительно ли у вас есть для этого? Почему вы не хотите создавать экземпляр Manager и сделать его доступным для кода, который опирается на него посредством инъекции зависимостей? Это сделает ваш код намного чище:

• Вы бы позволить ему быть проверяемым с различными путями инициализации
• Вам не нужны будет любая проверка «плохой» дубликат инициализации
• Вам не нужен будет для структурирования вашего кода вызова для указания единственной точки инициализации для этого класса. (Вы, возможно, потребуется сделать что-то подобное для IoC контейнера, конечно ...)
• Вы хотите разрешить ваш код, который зависит от того, чтобы быть более проверяемым слишком
• код, который зависит от Manager бы выразить эту зависимость более ясным образом

Я подозреваю, что вы не нашли подобных примеров, потому что это анти-шаблон.

Если вы сделать идти за текущий подход, вы действительно должны попытаться сделать его поточно-тоже ...

Answer 2

Не более думаю, что, если эта схема работает для вас, идти с Это. Не всегда есть «правильный» ответ, и попытка придерживаться жестких моделей и практик только ради того, чтобы придерживаться их тоже не является хорошей идеей. ИМХО.

Answer 3

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

Что вы можете сделать, это this. Вы можете скрыть метод от IntelliSense и аналогичный с этим атрибутом. Остановляет это от загромождения выпадающего списка

Answer 4

Ваша реализация не является потокобезопасной, но в остальном разумной. Если он предназначен для использования в многопоточной среде, добавьте блокировку.

В вашем примере открытый вопрос заключается в том, что должно произойти, если несколько вызывающих абонентов (возможно, из нескольких потоков) вызывают метод инициализации с различными параметрами. Это то, что делает ваш шаблон необычным и не позволяет использовать очевидный статический конструктор или инициализатор объекта.

Answer 5

Не можете ли вы использовать статический конструктор?

Конечно, у вас нет контроля над тем, когда этот конструктор вызван, но не знаю, является ли это требованием.

http://msdn.microsoft.com/en-us/library/k9x6w0hc(v=vs.80).aspx

Answer 6

Вы можете использовать одноплодный шаблон с параметрами только выставить определенную функциональность переменной Manager.

class Entity 
{ 
    private Manager _manager = null; 

    public Manager manager 
    { 
     get 
     { 
      return _manager; 
     } 
     set 
     { 
      if (manager == null) 
      { 
       _manager = value; 
      } 
     } 
    } 
    /* rest of class */ 
} 

Теперь вы можете использовать объект-менеджер как любую переменную, но повторные наборы не изменят значение.

this.manager = new Manager(0); // sets the manager 
this.manager = new Manager(1); // does nothing 

Теперь, чтобы завершить картину в конструкторе где-либо в какой-то функции сброса Вы можете сделать

this._manager = null;