Шаблон проектирования Singleton (одиночка), подбираю подходящий для моей задачи Опции

[Litkevich Yuriy]

Подбираю шаблон проектирования для моей задачи.
Задача такая:
Есть программа типа MDI, хочу сделать в ней многопользовательскую работу, в одно время работает только один пользователь.
В зависимости от группы пользователя ему становится доступным определенный, для данной группы, набор пунктов меню.

Я это так прикинул:
1-Нужно хранить переменную, например, uid, в которой указан код текущего пользователя/группы.
2-Нужен диалог ввода имени и пароля, который будет где-нибудь искать есть ли такая пара логин/пароль. Если есть, то устанавливать найденное значение в переменной uid. Если нет - ругнутся на пользователя.
3-Основное окно программы получает от диалога результат: ОК-пользователь найден, надо обновить меню, НЕ ОК - пользователь не найден, ничего не делать.

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

[Tonal]

Обычно синглетон (одиночка) без FreeInstance и без подсчёта ссылок пишется.
Простейший:

struct singleton_t {
  static singleton_t& instance() {
    static singleton_t inst;
    return inst;
  }
  //Здесь пишем нужные методы
  private:
    singleton_t() {/*код инициализации*/}
    ~singleton_t() {/*код очистки*/}
    singleton_t(const singleton_t&);
    singleton_t& operator=(const singleton_t&);
};

Мне кажется, он хорошо подойдёт, т.к. те проблемы, которые он имеет, в данном случае не существенны.

Собственно проблемы:
1) Возможные гонки потоков при создании.
Решаются или более хитрым методом instance - с правильными блокировками, или принудительным созданием до запуска потоков.
2) Обращение к разрушенному объекту. Когда кто-нибудь пытается обратится к instance, когда inst уже разрушен.
Т.к. разрушается экземпляр такого одиночки после выхода из main, то такое может происходить, только если обращение идёт из деструкторов других глобальных объектов.
Решение - или запретить такие обращения, или создавать одиночку в куче и никогда не убивать (хорошо описано у Александреску).
3) Неясный порядок разрушения. Когда такой одиночка захватывает ресурсы время жизни которых завязано на другие ресурсы, неподконтрольные одиночке - например он держит открытый запрос, а конектом к базе занимается приложение.
Решение - не делать так!
Другое решение - предоставить метод очистки, который должен вызываться перед закрытием коннекта к базе. После закрытия, или возвращать признак ошибки, либо брасать исключение (может быть опасно если вылетит в деструкторе), либо возвращать заглушки.

Сообщение отредактировал Tonal - 5.5.2008, 11:04