A-tit indd

Паттерны программирования игр
— Другой взгляд на паттерны проектирования
109
те самые призрачные классы, нужные, чтобы «нянчить» 
некоторые объекты. Я видел исходники, где чуть ли 
не у 
каждого
класса был свой менеджер: Монстр, Ме-
неджерМонстра, Частица, МенеджерЧастицы, Звук, 
МенеджерЗвука, МенеджерМенеджера. Иногда, ради 
разнообразия, их называют «Система» или «Движок», 
но смысл остается тем же.
И хотя такие классы-няньки бывают полезны, в боль-
шинстве случаев они отражают невежество в ООП. Об-
ратите внимание на следующие выдуманные классы.
class Bullet
{
public:
int getX() const {return x_;}
int getY() const {return y_;}
void setX(int x) {x_ = x;}
void setY(int y) {y_ = y;}
private:
int x_,
int y_;
};
class BulletManager
{
public:
Bullet* create(int x, int y)
{
Bullet* bullet = new Bullet();
bullet->setX(x);
bullet->setY(y);
return bullet;
}
bool isOnScreen(Bullet& bullet)
{
return bullet.getX() >= 0 &&
bullet.getY() >= 0 &&
bullet.getX() < SCREEN_WIDTH &&
bullet.getY() < SCREEN_HEIGHT;
}
void move(Bullet& bullet)

---

110
Одиночка (Singleton) — 
Паттерны программирования игр
{
bullet.setX(bullet.getX() + 5);
}
};
Возможно, я привел немного глупый пример, но мне 
часто встречался код, спроектированный точно так же, 
за исключением некоторых деталей. Если вы вни-
мательно на него взглянете, то станет очевидно, что 
BulletManager
должен быть одиночкой. Ведь всему, 
у чего есть 
Bullet
, понадобится менеджер. А сколько 
экземпляров 
BulletManager
вам нужно?
На самом деле правильный ответ —
ноль
. Вот мое 
предложение по решению проблемы «одиночки» для 
класса менеджера:
class Bullet
{
public:
Bullet(int x, int y)
: x_(x), y_(y)
{}
bool isOnScreen()
{
return x_ >= 0 && x_ < SCREEN_WIDTH &&
y_ >= 0 && y_ < SCREEN_HEIGHT;
}
void move() {x_ += 5;}
private:
int x_, y_;
};
Вот и все. Нет менеджера — нет проблем. Плохо спро-
ектированные одиночки часто — простые «помощни-
ки», они только добавляют функционала другому классу. 
Если можете, добавьте весь нужный функционал напря-
мую классу, которому требуется помощь. Вся суть ООП 
как раз в том, что объекты могут помогать сами себе.
Хотя помимо менеджеров имеются и другие пробле-
мы, где для решения мы могли бы использовать паттерн 

---