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

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


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



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

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

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

AS>...

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

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

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

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

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

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

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

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



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

AS>>...

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

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

B>

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

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

Здравствуйте, AlScan.

За последнее время очень часто вижу вопросы типа "Что делать с атрибутами? Ведь они разные у каждого объекта!"

Так, начнем по порядку.

Есть такой паттерн — Abstract Factory.
Его юзаем для того, чтобы создавать группы взаимо зависимых объектов. Т.е. тех объектов, которые точно знают что и зачем есть у других объектов из этой группы.

Есть такой паттерн — Bridge.
Его используем для отделения функций объекта. не связанных с хранением данных. Например, отрисовка объекта на экране.

Есть парадигмы ООП — полиморфизм и наследование.
Их используем для добавления новых объектов.

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

Если все же нужно определить поведение, то нужно воспользоваться паттерном Strategy, с помощью которого будет осуществляться контроль поведения объектов, но его нужно реализовать не для каждого конкретного экземпляра объектов, а для группы специвических объектов.

Это коротко.

ПРичем тут мост.... непонятно.
Нужен Билдер строящий комнату. а еще какойто внешний способ задавать описание комнаты (XML). , билдер принимает XML и стоит комнату.
Усе.

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

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

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

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

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

Так пусть и колонны, троны и т.д. будут уравнены в правах с 'комнатами'. Т.е. и 'комнаты', и 'колонны' представлены в виде интерфейса, который умеет отрисовывать себя, только конкретная имплементация этого интерфейса('комната') умеет агрегировать в себя другие имплементации этого же интерфейса. См. Gof Composite и отчасти POSA Whole-Part

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

M>ПРичем тут мост.... непонятно.
M>Нужен Билдер строящий комнату. а еще какойто внешний способ задавать описание комнаты (XML). , билдер принимает XML и стоит комнату.
M>Усе.

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

А описание комнаты обязательно задавать с помощью внешнего описания? А инкапсулировать в объекте (например в распорядителе может с помощью переключателя Swich) нельзя? В этом есть какой-то недостаток?

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

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

M>>ПРичем тут мост.... непонятно.
M>>Нужен Билдер строящий комнату. а еще какойто внешний способ задавать описание комнаты (XML). , билдер принимает XML и стоит комнату.
M>>Усе.

AS>Спасибо за ваше решение.
AS>Я тоже подумал вчера по поводу билдера. Но от моста как бы отказываться не хочу, лучше их попробовать совместить т.к. мне нужны две иерархии и абстракции и реализации для независимого их наращивания (а это может обеспечить мост).

AS> А описание комнаты обязательно задавать с помощью внешнего описания? А инкапсулировать в объекте (например в распорядителе может с помощью переключателя Swich) нельзя? В этом есть какой-то недостаток?

Ты хоть думал о том, что я сказал? Мост тебе здесь не нужен. Поверь, эта проблема решалась и я тебе сказал одно из решений. Не упирайся рогом, а подумай.

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

S>Здравствуйте, AlScan.

S>За последнее время очень часто вижу вопросы типа "Что делать с атрибутами? Ведь они разные у каждого объекта!"

S>Так, начнем по порядку.

S>Есть такой паттерн — Abstract Factory.
S>Его юзаем для того, чтобы создавать группы взаимо зависимых объектов. Т.е. тех объектов, которые точно знают что и зачем есть у других объектов из этой группы.

S>Есть такой паттерн — Bridge.
S>Его используем для отделения функций объекта. не связанных с хранением данных. Например, отрисовка объекта на экране.

S>Есть парадигмы ООП — полиморфизм и наследование.
S>Их используем для добавления новых объектов.

S>Использование этих трех вещей позволит забыть о том, что у объектов есть разные атрибуты и реализовывать каждый случай по отдельности не думая о том, как он может отразиться на поведении других объектов.

S>Если все же нужно определить поведение, то нужно воспользоваться паттерном Strategy, с помощью которого будет осуществляться контроль поведения объектов, но его нужно реализовать не для каждого конкретного экземпляра объектов, а для группы специвических объектов.

S>Это коротко.

Спасибо за ответ.
Если можно подскажите пожалуйста правильно ли я понимаю следующее:

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

-абстрактная фабрика в моей задачи мне не поможет т.к. речь идет о семействе объектов СВЯЗАННЫХ между собой т.е. например с этой комнатой только этот трон и т.д. А мне как бы нужно немного другое в одной галереи одна колонна а в другой та же колонна толь их несколько.

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

AS>-в паттерне мост уточненная абстракция (в моем случае тронный зал или галерея) не должна агрегировать другие объекты в качестве членов данных и вообще никаких членов данных кроме указателя , т.к. это уже будет привязка к реализации. Вся реализация только через единственный указатель на неё. задача уточненной абстракции только в том чтобы расширить интерфейс базовой абстракции т.е. своего базового класса.

Знаешь, мне не понятно, что ты вкладываешь в фразу: "уточненная абстракция не должна агрегировать другие объекты в качестве членов данных и вообще никаких членов данных кроме указателя". Поэтому далее напишу, что думаю об иерархии в твоей системе единиц.
Твой тронный зал, или галерея, являются уточнением понятия помещения. Помещение, в свою очередь, является уточнением объекта. Объектами могут быть колонны, стулья, комнаты и пр. Могут ли одни объекты содержать другие? Ответ очевиден — могут. И даже больше того: один объект может содержать сколько угодно других объектов. Рационально будет поместить эту зависимость как можно выше в иерархии.

AS>-абстрактная фабрика в моей задачи мне не поможет т.к. речь идет о семействе объектов СВЯЗАННЫХ между собой т.е. например с этой комнатой только этот трон и т.д. А мне как бы нужно немного другое в одной галереи одна колонна а в другой та же колонна толь их несколько.

Как раз для этого и нужна фабрика. С помощью нее ты сможешь создавать группы связанных объектов.
Кроме того, логику создания колон в галерее ты тоже пропишешь в фабрике "и будет тебе счастье", как говорят.

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

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

AS>>-в паттерне мост уточненная абстракция (в моем случае тронный зал или галерея) не должна агрегировать другие объекты в качестве членов данных и вообще никаких членов данных кроме указателя , т.к. это уже будет привязка к реализации. Вся реализация только через единственный указатель на неё. задача уточненной абстракции только в том чтобы расширить интерфейс базовой абстракции т.е. своего базового класса.

S>Знаешь, мне не понятно, что ты вкладываешь в фразу: "уточненная абстракция не должна агрегировать другие объекты в качестве членов данных и вообще никаких членов данных кроме указателя". Поэтому далее напишу, что думаю об иерархии в твоей системе единиц.
S>Твой тронный зал, или галерея, являются уточнением понятия помещения. Помещение, в свою очередь, является уточнением объекта. Объектами могут быть колонны, стулья, комнаты и пр. Могут ли одни объекты содержать другие? Ответ очевиден — могут. И даже больше того: один объект может содержать сколько угодно других объектов. Рационально будет поместить эту зависимость как можно выше в иерархии.

AS>>-абстрактная фабрика в моей задачи мне не поможет т.к. речь идет о семействе объектов СВЯЗАННЫХ между собой т.е. например с этой комнатой только этот трон и т.д. А мне как бы нужно немного другое в одной галереи одна колонна а в другой та же колонна толь их несколько.

S>Как раз для этого и нужна фабрика. С помощью нее ты сможешь создавать группы связанных объектов.
S>Кроме того, логику создания колон в галерее ты тоже пропишешь в фабрике "и будет тебе счастье", как говорят.


Спасибо.