Реализация прототипа в GoF

Question

(Этот вопрос больше для людей, которые имеют доступ к книге, иначе сложно представить ее в контексте)

Я читал книгу 'Шаблоны проектирования' от GoF, и есть предложение, которое меня немного смущает, под 'Шаблоны создания-> Прототип-> Пример кода' (стр. 124).

В нижней части страницы находится реализация для BombedWall, которая, как я понимаю, является конкретным прототипом, поскольку он наследует от Wall и переопределяет виртуальную функцию Clone(). BombedWall также определяет другой метод , HasBomb(), неизвестный для любых клиентов, использующих обычный интерфейс Wall.

Единственный способ хранения BombedWall в MazePrototypeFactory (клиент Prototype) - это Wall* (возвращается из BombedWall::Clone), и единственный способ впоследствии получить HasBomb(), насколько Я понимаю, что нужно выполнить понижение этого Wall* до BombedWall* (динамического или статического, в зависимости от того, знаю ли я тип), а затем я могу получить доступ к методу HasBomb().

Все это казалось мне в порядке; но потом позже автор говорит (та же страница, последнее предложение, второй последний абзац):

"Клиенты никогда не должны понижать возвращаемое значение Clone до нужный тип "

Что? Тогда как мне добраться до HasBomb()?

Должно быть, я что-то упустил ...

Answer 1

Я дал ответ и полностью переписал его сейчас:)

По сути, MazePrototypeFactory знает только о базовых классах, которые он может использовать. Он ничего не знает ни о одном из подклассов, которые вы собираетесь создать, но он все же должен иметь возможность поместить любой возможный подкласс в лабиринт.

Этот шаблон в основном гарантирует, что MazeFactory получит указатель типа, который он понимает, Wall, чем необходимость в модификации MazeFactory для создания объектов всех подклассов.

MazeFactory - клиент, упомянутый на стр. 124. Ему не нужно знать о HasBomb, чтобы построить лабиринт.

Answer 2

Я предполагаю, что этот метод существует только для указания того, что BombedWall - это другой класс с расширенным общедоступным интерфейсом.Однако этот интерфейс не используется в контексте примера: алгоритм построения лабиринта не различает типы стен, в то время как другие подсистемы (например, движок рендеринга) могут делать это.