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

При разработке больших проектов, часто возникает необходимость обращаться из одного модуля программы к объектам, существующим в другом модуле. Такие объекты, как правило, существуют в единичных экземплярах, поэтому наиболее распространенной практикой является создание глобальных объектов данного типа и ссылка на них из других модулей программы с применением ключевого слова extern. Так, например, при создании ATL проекта в среде MSVC++, мастер проекта создает экземпляр класса – наследника от CComModule, _Module, в главном файле проекта, и помещает объявление extern CMyModule _Module в stdafx.h, что делает доступным объект _Module из других файлов проекта. Однако при таком подходе отсутствует механизм, предотвращающий создание нескольких объектов данного типа. Кроме того, поскольку объект создается статически, отсутствует возможность управлять процессом его создания. То есть, объект создается автоматически, до момента его фактического применения в программе. Это может приводить к некоторым неприятным последствиям: если объект работает с некоторой инфраструктурой, то инициализация и освобождение этой инфраструктуры должны быть помещены, например, в этот же класс.

class BusinesLogic //использует инфраструктуру COM

{

public:

BusinesLogic () {

CoInitializeEx(NULL, COINIT_MULTITHREADED);

//некая работа с COM

}

~BusinesLogic () {

CoUninitialize();

}

};

Глядя на следующий фрагмент, нельзя сказать, была ли инициализирована инфраструктура, а если да, то ничего нельзя сказать о выбранной потоковой модели COM. Как следствие, такой код – источник ошибок и возможных проблем с их диагностикой.

BusinesLogic BL;

void main() {

HRESULT hr;

IUnknown *p;

hr=CoCreateInstance(CLSID_AppartmentThreadClass, NULL, CLSCTX_INPROC_SERVER, IID_IUnknown, (void**)&p);

}

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

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

class Singleton {

static Singleton* _self;

protected:

Singleton(){}

public:

static Singleton* Instance() {

if (!_self) _self = new Singleton();

return _self;

}

//методы

void aFunc1();

void aFunc2();

//данные

int aData;

};

Singleton* Singleton::_self=NULL;

ПРИМЕЧАНИЕКонструктор класса объявлен в защищенной секции. Благодаря этому отсутствует возможность создавать объекты класса по оператору new или статически. Вместо этого для конструирования объекта служит метод Instance(), который гарантирует, что в программе будет существовать только один экземпляр данного класса.

Таким образом, класс Singleton инкапсулирует в себе методы и свойства данной сущности, может быть доступен из любого места программы благодаря методу Instance(), а, кроме того, теперь мы можем управлять временем жизни этого объекта. Вот пример использования класса Singleton:

#include "app.h"

void main() {

Application* application = Application::Instance();

application->Run();

delete application;

}

#include

using std::string;

class Window;

class Application {

static Application* _self;

Window *wnd;

protected:

Application(){}

public:

static Application* Instance();

int loadIniInt(string& section, string& var);

void saveIniInt(string& section, string& var, int val);

void Run();

};

Application* Application::Instance() {

if(!_self) _self = new Application();

return _self;

}

int Application::loadIniInt(string& section, string& var) {

printf("loadIni\n");

return 100;

}

void Application::saveIniInt(string& section, string& var, int val) {

printf("saveIni\n");

}

void Application::Run() {

wnd=new Window();

//цикл обработки сообщений

delete wnd;

}

Application* Application::_self=NULL;

#include "app.h"

class Window {

int width;

int height;

public:

Window() {

Application *p=Application::Instance();

p->loadIniInt(string("Window"), string("width"));

p->loadIniInt(string("Window"), string("height"));

}

~Window() {

Application *p=Application::Instance();

p->saveIniInt(string("Window"), string("width"), width);

p->saveIniInt(string("Window"),string("height"), height);

}

};

Этот листинг показывает, как можно организовать каркас оконного приложения, используя паттерн Singleton. Из класса окна требуется доступ к некоторым функциям объекта Application. Поскольку объект приложения существует всегда в одном экземпляре, то он реализует паттерн Singleton, а доступ к объекту приложения из объекта окна осуществляется благодаря методу Instance().

В приведенной выше реализации класса Singleton, есть метод создания объекта, но отсутствует метод его удаления. Это означает, что программист должен помнить в каком месте программы объект удаляется. Другая проблема, связанная с удалением объекта из памяти, возникает при полиморфном использовании объектов класса. Рассмотрим, например, такой код.

class Client {

Singleton * _pS;

public:

SetObject(Singleton *p) {_pS=p;}

~Client(){delete _pS;}

};

void main() {

Client c1,c2;

c1.SetObject(Singleton::Instance());

c2.SetObject(Singleton::Instance());

}

Эта программа будет пытаться удалить дважды один и тот же объект, что приведет к исключительной ситуации в программе. При выходе из контекста функции main, сначала будет вызван деструктор объекта c2, который удалит объект класса Singleton, а затем то же самое попытается сделать и деструктор объекта c1. В связи с этим, хотелось бы иметь механизм, позволяющий автоматически отслеживать ссылки на объект класса Singleton, и автоматически удалять его только тогда, когда на объект нет активных ссылок. Для этого используют специальный метод FreeInst(), удаляющий объект только в случае, если активных ссылок на него нет.

Другая задача, которую надо решить – запрет удаления клиентом объекта Singleton посредством оператора delete. Это решается помещением деструктора в секцию protected.Тем самым, клиенту ничего не остается, как использовать пару Instance()/FreeInst() для управления временем жизни объекта.