Всем привет. Подскажите пожалуйста как можно в данном случае спроектировать задачку. Заранее большое спасибо.

Задача: нарисовать цепочку комнат (типа лабиринта), но не сразу все, а пользователь на выходе из одной комнаты выбирает комнату которую хочет увидеть (и то как она реализована) такая и создаётся следующей. Например комнаты могут быть следующие : тронный зал (эльфов, людей), кабинет(эльфов, людей) и т.д. Реализованы комнаты могут быть следующим образом: в виде шара, в виде многоугольника (например шесть стен или восемь или четыре), в виде цилиндра (т.е. пол в виде круга или эллипса). При этом в каждой комнате есть различные предметы (назавем их атрибутвми), например: в тронном зале трон или в галереи колонны. Количество атрибутов может быть разное. Например: в тронном зале эльфов один трон, а у людей два и т.д. Внутри комнаты можно поворачиваться налево направо, шагать вперед и назад при этом вид комнаты вместе с атрибутами соответственно изменяется (например масштабируется при движении вперед).


Требования:
1.Абстракция (комната) и реализации должны расширяться новыми подклассами (чтобы легко можно было ввести новый вид комнат например галерею или подвал, а так же реализации например в виде треугольника);
2.Изменения в реализации не должны сказывать на клиентах т.е. клиентский код не должен перекомпилироваться;
3.Реализацию нужно выбирать во время выполнения программы (пользователь выбирает);
4.Объекты должны создаваться косвенно т.е. чтобы имя реального класса в клиентском коде не засветить;
5.Не плодить объекты в огромном количестве при увеличении функциональности.



Возможный вариант решения: разделить абстракцию и её реализацию на две иерархии (паттерн Мост). Абстракция содержит указатель на реализацию и делегирует этому объекту свои запросы на отображение. Т.о. можно комбинировать абстракции с различными реализациями, при этом не плодить объектов огромное количество.

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