Я уже писал об этом паттерне в "Идиомах и стилях" , но чтобы не
нарушать порядок, еще раз вернусь к нему.
В Вашей игре есть некий склад с ресурсами. Ваши воины там берут еду, танки
загружают снаряды. Склад может быть только один. Как гарантировать, что Вы
случайно не создали второй склад? Что юниты в любой части игры обратятся
обязательно к одному складу? Или может Вы создали абстрактную фабрику, и опять
же хотите, чтобы она была одна?
Единичность гарантировать просто - нужна такая фабрика, которая отработала бы
только один раз - а на остальные запросы выдавала уже построенный экземпляр.
Ничего страшного, если фабрика будет сама тем классом, который производит. Это
мы уже видели в прототипе.
// декларация одиночки
class CSingleton
{
public:
// эта функция выдает единственный экземпляр
static CSingleton* GetInstance (void);
// удалить его тоже когда-то придется.
static void DestroyInstance (void) { if (m_instance) delete m_instance;} ;
private:
// статический указатель на единственный экземпляр
static CSingleton* m_instance;
protected:
CSingleton(){};
};
// Инициализация проходит нулем.
CSingleton* CSingleton::m_instance = NULL;
// Обращение к единственному экземпляру.
CSingleton* CSingleton::GetInstance()
{
if (!m_instance) m_instance = new CSingleton;
return m_instance;
}
О порождающих паттернах все. Я написал самый минимум. К ним относятся.
Абстрактная фабрика (Abstract Factory).
Строитель (Builder).
Прототип (Prototype).
Фабричный метод (Factory Method).
Одиночка (Singleton).
Порождающие паттерты создают новые экземпляры при помощи производящих
функций, подобные следующему :
CProduct* CFactory::createProduct () { return new CProduct;};
, так что фабрика создает экземпляр, но не управляет его временем жизни. Это
значит, что кто-то должен заботиться о правильном уничтожении экземпляров.
Выбирать имеет смысл между абстрактной фабрикой, строителем и прототипом;
одиночка и фабричный метод имеют специальное применение, они слишком негибкие.
Все остальные подробности - у Гаммы сотоварищи; Addison-Wesley печатало
"Desing Patterns" 14 раз - это о чем то говорит?
By Albert
Makhmutov.
Тестирование параллельного программного обеспечения представляет собой более
сложную задачу по сравнению с тестированием последовательной программы. Программист
должен знать о подводных камнях при тестировании параллельного кода, имеющихся
методологиях и инструментарии.
Аннотация. В статье кратко рассматривается архитектура AMD64 компании AMD и ее
реализация EM64T компании Intel. Описаны особенности архитектуры, ее возможности,
достоинства и недостатки.