Здравствуйте, bolshik, Вы писали:

Спасибо за хороший совет . Он пригодится в дальнейшем, когда пользователь будет как-то хулиганить в комнате . Пока же ситуация проще: внутри комнаты он может только смотреть на все кругом и больше ничего.

Я писал 'пользователь может выбрать что угодно' в смысле выбрать любой вид комнаты (тронный зал, галерею и пр.) и любую реализацию (например эльфийскую в форме шара или людскую с четырьмя стенами ). Сами классы реализаций выполняют только одну задачу: рисуют комнату соответствующего вида (например с шестью стенами) а вот атрибуты (колонны, троны и пр.) они не рисуют. Не рисуют т.к. в этом случае можно легко комбинировать виды комнат с разными реализациями. А атрибуты это уже другое не хочу привязывать к виду комнаты т.к. у тронного зала эльфов может быть их пять, людей – вообще нет.

Вопрос в том что кому-то надо доверить отрисовку и атрибутов но я не могу решить кому.



B>Здравствуйте, AlScan, Вы писали:

AS>>...

AS>>Но возникает вопрос: как вписать в эту схему (иерархию) атрибуты? Ведь у каждого вида абстракции свое количество атрибутов и различный их состав. Если впихнуть отображение атрибутов в класс реализации то это не особо хорошо т.к. в каждом классе реализации должны храниться описания ВСЕХ возможных атрибутов (т.к. пользователь может выбрать что угодно) и потом нарушается правило «один объект – одна задача».

B>Можно понимать 'пользователь может выбрать что угодно' т.о., что пользователь послает интерфейсу комнаты сообщение вида 'я нахожусь там-то, делаю действие 'взять''. Действия тоже объединены в иерархию вида

B>

B>             Action
B>                |
B>  ______________ _____________
B> |      |       |      |      |
B>Get    Put     Use    Hit    ...
B>

B>В ответ на действие комната возвращает его результат, т.е., например, на Get, про которое говорилось выше, может вернуться объект Crown(взяли с трона корону).