Примеры использования Паттерн Singleton (Одиночка)

Федоров Дима

Резюме

1. В классе Singleton конструктор должен быть объявлен в защищенной секции для предотвращения создания объекта способом, отличным от вызова метода Instance.

2. Деструктор также следует поместить в защищенную секцию класса, чтобы исключить возможность удаления объекта оператором delete.

3. Для автоматического подсчета ссылок при освобождении объекта следует применять специальный метод, такой как FreeInst.

4. При наследовании от класса, реализующего паттерн Singleton, конструктор

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

5. Если предполагается полиморфная работа с классами, наследуемыми от одного базового класса, причем некоторые классы потомки реализуют паттерн Singleton, а некоторые нет, следует в базовом классе определить метод FreeInst как виртуальный. Базовый класс предоставляет реализацию по умолчанию этого метода, просто вызывая оператор delete this. В классах-потомках, реализующих паттерн Singleton, при реализации метода FreeInst, используйте механизм подсчета ссылок.

6. Если используется параметризированная версия Singleton, то в производных классах следует объявить базовый класс (Singleton) дружественным.

Литература

1. http://www.firststeps.ru/theory/c/r.php?29

2. http://ooad.asf.ru/patterns/patterninfo.asp?ID=13

3. Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес “Приемы объектно-ориентированного проектирования. Паттерны проектирования”

Комментарии: 

Как бы так это заделать???

Во первых, статья очень хорошая и полезная, спасибо. Применил в реальной программе я этот сингелтон и остался очень доволен. Но мне надо было несколько изменить поведение исходного класса. У меня ситуация такая: есть клиент, который шлёт запросы на сервер, на сервере есть класс, который создаёт и хранит необходимые для обработки этих запросов таблицы. Но беда в том, что после обработки очередного запроса мне не надо уничтожать объект, т.к. эти запросы идут сериями по многу штук подряд, а удалять объект надо в конце серии... Я сделал во что:

template <class T>

T* Singleton<T>::Instance

{

if(!_self)

{

_self=new T;

_refcount++; // вот это

}

_refcount++;

return _self;

}

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

Ну, в довесок хочу воткнуть так вот полу-смарт

указатель:

template<class T>

class TSingeltonPtr

{

T *_t;

public:

TSingeltonPtr { _t = T::Instance; }

~TSingeltonPtr { if(_t) _t->FreeInst; }

operator T* { return _t; }

T* operator-> { return _t; }

bool operator! const { return _t==0; }

};

использование:

class Derived : public Singleton<Derived>

{

void foo;

...

};

void bar

{

TSingeltonPtr<Derived> sp;

if ( !sp ) return;

sp->foo;

}

konst 11.12.2002 19:17

Маленькое замечание

Все таки непонятно, откуда пошла дурацкая мода в с++ коде давать данным-членам класса символ подчеркивания в качестве префикса? То есть, и так ясно откуда...

Но ведь c++ не java... Например на MCVC++ код с такими префиксами не компилируется иногда. Ведь сказано же, зарезервировано под надобности компиляторов. Или это специально так отформатировано, чтобы читать было красивее? ;)

А статья действительно хорошая, удивило то что почти не пересекается с [3] ;)

Пересыпкин Михаил Алексеевич 3.12.2002 16:39

зачем возвращать указатель?

Еще хочу добавить: почему Instance возвращает указатель а не ссылку? Тогда и путаницы с delete не будет!

Sergeem 19.11.2002 12:56

взаимодействие синглтонов

Интересно обсудить эту тему.

Например у меня есть синглтон - менеджер памяти, синглтон - БД-клиент, и т.д.

Тогда менеджер памяти должен "уходить" последним, поскольку другие с-тоны могут освобождать память в своих деструкторах. Интересный вариант есть в loki. Я реалиовал свою модель. феслт кому интересно, могу поделиться или обсудить где-нить в С++ форуме. 

Sergeem 19.11.2002 12:52