Имеет ли смысл создавать абстрактную фабрику для фабрик?
Я искал эти паттерны и обнаружил, что мы можем создать Factory за Abstract factories и это действительно имело бы смысл. Я делаю следующий пример, опираясь на какую-то книгу по C ++.
Представьте, что у нас есть два абстрактных класса в игровом приложении: Monster а также SuperMonster,
На сложном уровне у нас также есть свои реализации:
SillyMonster, MediumMonster а также HardMonster и так для SuperMonsters.
Теперь мы можем создать три фабрики объектов с одним и тем же базовым классом:
class AbstractEnemyFactory
{
public:
virtual Soldier* MakeSoldier() = 0;
virtual Monster* MakeMonster() = 0;
virtual SuperMonster* MakeSuperMonster() = 0;
};
class EasyLevelEnemyFactory : public AbstractEnemyFactory
{
public:
Monster* MakeMonster()
{
return new SillyMonster;
}
SuperMonster* MakeSuperMonster()
{
return new SillySuperMonster;
}
};
//The other two factories
И мне кажется вполне естественным, если мы создадим AbstractEnemyFactoryFactory который собирается создать соответствующий AbstractEnemyFactory реализация в зависимости от того, какой уровень был выбран геймером во время выполнения.
Вопрос: Имеет ли смысл инкапсулировать ObjectFactory в AbstractFactory?
Я имею в виду, мы создаем Abstract Factory который сам собирается создать Object Factories, а не конкретные объекты, которые в свою очередь создают конкретные объекты. Я не мог найти более или менее разумный пример …
Решение
Если вы используете AbstractEnemyFactoryFactory создать AbstractEnemyFactory тогда вы снова окажетесь в проблеме «Кто позаботится о создании AbstractEnemyFactoryFactory«И тогда вы можете попытаться создать другой AbstractEnemyFactoryFactoryFactory и так далее….
Наличие паттернов AbstractFactory означает, что где-то в вашем приложении вам понадобится своего рода переключатель (обычно управляемый входами графического интерфейса), который создает оценку ConcreteFactory, когда игрок выбирает сложность игры в вашем случае.
Я хочу сказать, что обычно инкапсулировать ObjectFactory в AbstractFactoryFactory не является неправильным, но это следует делать в ситуациях, когда ObjectFactory не единственный, который нужно создать (например, у вас может быть фабрика для деревьев, которая будет создавать конкретные деревья по-разному, если игрок выбирает жесткий или простой режим). В этом случае AbstractFactoryFactory будет обрабатывать создание нескольких объектов фабрики, и это может быть полезно.
Но если создание EnemyFactory напрямую контролируется модулями высокого уровня (GUI), просто оставьте его простым и создайте EasyLevelEnemyFactory или HardLevelEnemyFactory
РЕДАКТИРОВАТЬ:
Для уточнения: следуя примеру дерева и врага, MediumGameFactory создает MediumEnemyFactory завод и MediumTreeFactory, в то время как EasyGameFactory создает EasyEnemyFactory а также EasyTreeFactory, Таким образом, в верхней части вашего приложения вы просто должны создать MediumGameFactory или же EasyGameFactory в зависимости от сложности игры (здесь идет переход), и эти две фабрики будут обрабатывать все остальное. Следовательно, вам не нужно вручную создавать все небольшие фабрики в приложении.
Другие решения