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

В Вашей игре есть некий склад с ресурсами. Ваши воины там берут еду, танки загружают снаряды. Склад может быть только один. Как гарантировать, что Вы случайно не создали второй склад? Что юниты в любой части игры обратятся обязательно к одному складу? Или может Вы создали абстрактную фабрику, и опять же хотите, чтобы она была одна?

Снова к нашей игре.

Вернемся к нашей гаме. Пусть Вам нужно стоить здание. Здание строится из блоков: целых комнат или залов, панелей, перекрытий, перегородок, стен, оконных блоков, фундаментов и кирпичей. Что интересно, соединив два здания, Вы получаете осмысленый результат: другое здание. Это значит, что и само здание является блоком. В то же время, панели можно собрать из кирпича, фундаменты тоже, и так далее. Всякий блок состоит из других - а в основе пирамиды лежат голые кирпичи, деревяшки и стекла.

Немного отвлечемся от нашей игры. Пусть Ваша программа управляет файлами в различных файловой системе, для чего Вы от класса CFile порождаете потомки CFATFile и CNTFSFile. А еще файлы могут быть либо текстовыми, либо двоичными - да еще и в каждой файловой системой. Если просто порождать потомки, то получится уже четыре класса. Кроме того, код будет дублировать друг друга, а подклассы окажутся привязанными к реализации - поскольку никто не гарантирует одинакового поведения для CFATTextFile и CNTFSTextFile.

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