Д. Стефенс - C++. Сборник рецептов

Singleton* Singleton::getInstance() {

if (inst_ == NULL) {

inst_ = new Singleton();

}

return(inst_);

}

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

Singleton* p1 = Singleton::getInstance();

И если вы не хотите, чтобы клиенты работали с указателями, то можно возвращать ссылку.

Singleton& Singleton::getInstance() {

if (inst_ == NULL) {

inst_ = new Singleton();

}

return(*inst_);

}

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

Рецепт 8.3.

Требуется определить интерфейс, который будет реализовываться производными классами, но концепция этого интерфейса является абстракцией и не должна наследоваться сама по себе.

Создайте абстрактный класс, который определяет интерфейс, объявляя, по крайней мере, одну из своих функций как чисто виртуальную ( virtual). Создайте классы, производные от этого абстрактного класса, которые будут использовать различные реализации, обеспечивая при этом один и тот же интерфейс. Пример 8.10 показывает, как можно определить абстрактный класс для чтения настроечного файла.

Пример 8.10. Использование абстрактного базового класса

#include

#include

#include

using namespace std;

class AbstractConfigFile {

public:

virtual ~AbstractConfigFile() {}

virtual void getKey(const string& header,

const string& key, strings val) const = 0;

virtual void exists(const string& header,

const string& key, strings val) const = 0;

};

class TXTConfigFile : public AbstractConfigFile {

public:

TXTConfigFile() : in_(NULL) {}

TXTConfigFile(istream& in) : in_(&in) {}

virtual ~TXTConfigFile() {}

virtual void getKey(const string& header,

const string& key, strings val) const {}

virtual void exists(const string& header,

const strings key, strings val) const {}

protected:

istream* in_;

};

class MyAppClass {

public:

MyAppClass() : config_(NULL) {}

~MyAppClass() {}

void setConfigObj(const AbstractConfigFile* p) {config_ = p;}

void myMethod();

private:

const AbstractConfigFile* config_;

};

void MyAppClass::myMethod() {

string val;

config_->getKey("Foo", "Bar", val);

// ...

}

int main() {

ifstream in("foo.txt");

TXTConfigFile cfg(in);

MyAppClass m;

m.setConfigObj(&cfg);

m.myMethod();

}

Абстрактный базовый класс (часто называемый ABC — abstract base class) — это класс, для которого невозможно создать экземпляры, и, таким образом, он выполняет роль исключительно интерфейса. Класс является абстрактным, если он объявляет, по крайней мере, одну чисто виртуальную функцию или наследует функцию без реализации. Таким образом, если требуется создать экземпляр подкласса ABC, то он должен реализовать все виртуальные функции, что означает, что он будет поддерживать интерфейс, объявленный в ABC.

Подкласс, который наследуется от ABC (и реализует все его чисто виртуальные методы), поддерживает контракт, определенный интерфейсом. Рассмотрим классы MyAppClassи TXTConfigFileиз примера 8.10. MyAppClassсодержит указатель, который указывает на объект типа AbstractConfigFile.

const AbstractConfigFile* config_;

(Я сделал его const, потому что МуАррСlassне должен изменять настроечный файл, а только читать из него.) Пользователи могут указать используемый в MyAppClassнастроечный файл с помощью функции установки значения setConfigObj.

Когда приходит время использовать в MyAppClassнастроечный файл, как это делает MyAppClass::myMethod, можно вызвать любую из функций, объявленных в AbstractConfigFile, независимо от реально используемого типа настроечного файла. Это может быть TXTConfigFile, XMLConfigFileили любой другой, который наследуется от AbstractConfigFile.

Это полиморфное поведение является следствием наследования: если код ссылается на объект базового класса, вызов виртуальных функций для него приведет к их динамической переадресации и вызову правильных версий подкласса этого класса при условии, что реальный объект, на который ссылается код, является объектом этого подкласса. Но это происходит независимо от того, является ли базовый класс ABC или нет. Так в чем же разница?

Здесь имеется два различия. Чисто виртуальный класс (ABC, который не предоставляет никаких реализаций) служит только как контракт, которому должны подчиняться все подклассы, если требуется создавать их объекты. Часто это означает, что проверка на принадлежность подкласса к чисто интерфейсному классу может не сработать (что означает, что нельзя сказать, что объект подкласса является также и объектом базового класса), но что сработает проверка «ведет себя как». Это позволяет различать то, чем объект является, оттого, что он может сделать. Спасибо Супермену. Он человек, но он также и супергерой. Супергерои могут летать как птицы, но сказать, что супергерой — это птица, будет неверно. Иерархия классов для Супермена может выглядеть так, как это показано в примере 8.11.

Пример 8.11. Использование чистого интерфейса

class Person {

public:

virtual void eat() = 0;

virtual void sleep() = 0;

virtual void walk() = 0;

virtual void jump() = 0;

};

class IAirborne {

public:

virtual void fly() = 0;

virtual void up() = 0;

virtual void down() = 0;

};

class Superhero : public Person, // Супергерой «является» человеком

public IAirborne { // и летает

public:

virtual void eat();

virtual void sleep();

virtual void walk();

virtual void jump();

virtual void fly();

virtual void up();

virtual void down();

virtual ~Superhero();

};

void Superhero::fly() {

// ...

}

// Все виртуальные методы реализуем в родительских классах супергероя...

int main() {

Superhero superman;

superman.walk(); // Супермен может ходить как человек

superman.fly(); // или летать как птица

}

Однако летать может огромное количество объектов, так что не стоит называть этот интерфейс, например, IBird. IAirborneуказывает, что всё, что поддерживает этот интерфейс, может летать. Все, что он делает, — это позволяет клиентскому коду быть уверенным, что если он работает с объектом, наследуемым от IAirborne, клиентский код может вызвать методы fly, upи down.

Второе различие состоит в том, что ABC может определить абстрактную сущность, которая не имеет смысла как объект, так как она, по сути, является обобщением. В этом случае проверка на принадлежность при наследовании выполняется, но ABC — это абстракция, так как сам по себе он не содержит реализаций, которые могут наследоваться объектами. Рассмотрим класс AbstractConfigFileиз примера 8.10. Имеет ли смысл создавать объект типа AbstractConfigFile? Нет, имеет смысл только создавать различные виды настроечных файлов, которые имеют конкретное представление.