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

Вот моя диаграмма.
Выходит, что класс CMap. Отвечает и за саму карту и за ее отрисовку. Тут нужно создать новый класс, который будет рисовать. Вопрос такой, этот класс лучше сделать частью формы с отношением Композиция. Либо частью класса CMap тоже композицией. Или его еще куда можно засунуть?
Тут возникает следующий вопрос на моей диаграмма видно, что класса Enemy и Player так же через композицию относятся к классу CMap. Это как бы по своей сути верно, но у меня оно реализовано так, что функция которая проверяет может ли игрок походить в случае если может, то изменяет этот массив, который находится в классе CMap. Поэтому, как он мне сказал, туже композицию надо провести от Player к CMap и так же от Enemy. И выходит, что тут получается обратная связь, а он говорит, что нижние классы ничего не должны знать о верхних и ничего не должны менять.
Поэтому возвращаясь к новому классу Который должен рисовать карту, то он же тоже будет получать массив из СMap, чтобы что-то нарисовать, хотя он же ничего не изменяет поэтому тут будет просто Ассоциация?

Вот собственно и все, что хочу уточнить.
Спасибо.

я бы так сделал, наверное

Это все через Агрегацию?
Хорошо даже если и так, то Игрок должен ходить как-то, функции ходьбы у меня в классе Игрока, но для перехода ему нужно знать, где можно походить, потому я и посылаю из класса Карты ему массив с картой и тот его изменяет, а так нельзя сказали. В данном примере, я тоже не вижу возможности как таковой ходить игроку не зная куда.
К стати вот еще по этому поводу, поскольку игрок должен быть сам по себе и не зависеть от класса Карты, то выходит, что мне нужно будет переместить функции перехода в другой класс, а именно сказали, что каждый класс должен отвечать только за свои действия, то в класс Карты помещать не стоит и нужно будет еще сделать 1 класс Перехода, который будет отвечать только за переход. При этом выходит, что он тоже должен знать, массив с картой, чтобы проверять можно ли перейти... Тогда функции перехода все будут в этом классе, а в классе игрока ничего и не остается.   Вот вроде выходит, что должны быть классы CMap, Drawer, Player, Enemy, Walker.
Как бы теперь правильно связи расставить...
Игрок и Враг явно зависят от Карты через Композицию.
Дровер получает массив с картой из класса Карты т.к. ему нужно знать что рисовать.(Ассоциация?)
Волкер... даже не знаю куда его лучше всунуть, поскольку он вроде как зависит от Карты при этом ему нужно будет изменять координаты всех на карте...
Есть идеи?

Вся наша жисть - игра...
Мы в ней игроки. Действуем на поле Земля.
Отсюда - отношения:
1. Игра содержит землю и игроков, передавая ход
2. Игроки знают о Земле (карте), на которой идут действия
3. Игроки знают и о других игроках (возможно, посредством анализа карты)
4. Карта содержит текущее положение - что/кто где находится

Итак, Game агрегирует Map и Player, являясь связующим звеном в передаче информации и управляющая процессом
Player знает о Map (имеет ссылку)
Map независима, имеет методы, позволяющие изменить/получить текущее состояние

Так это по сути,то что у меня есть сейчас, за исключением обобщенного класса Гейм.
У меня сейчас так все и расставлено, Карта содержит Игроков, Игрок знает о карте(внутри указатель инициализирующийся через Конструктор).
Вот только, преподавателю необходима структура следующего вида.
Если посмотреть на мою диаграмму:
Форма - ничего не знает о том, кто ее вызывает, но знает, что содержит она.
Класс Карты - не важно ему, где он находится, важно только, то что он содержит.
Класс Игрок\Враг - им не важно куда они подключены, важно только, что ниже.

Вот и выходит, что не должно быть обратной связи от Игрока к Карте, потому, что Игрок в идее не знает, какой класс находится выше него. И поэтому действия нужно выполнять, где-то выше и потом какими либо методами, сообщать игроку, что у него что-то изменилось. А поскольку условие стоит так, что один класс отвечает только за себя, то класс Карты не может выполнять обработку Ходьбы. Как я написал придется добавлять еще 1 класс, который после обработки будет в низ(Игрокам) отправлять сообщение, что изменились координаты и т.п.
Хотя лично я, не вижу почему ему не подошел мой вариант, либо те что вы предложили.

неправильно это.



тут нет "выше/ниже", тут кооператив. для его организации и нужен Game. А карта лишь имеет состояние, умеет сообщать о нем, менять его и (возможно) рисовать себя.

Нет. Game имеет принципиальное значение.

Добавлено через 2 минуты и 52 секунды
вот тут основная ошибка:

не зависят.

Хорошо, вопрос, почему класс Гейм агрегирует Карту и Игрока? Это же значит, что Карта и Игрок должны быть созданы, где-то в другом месте и не зависеть от Гейма.
И вопрос остается, перемещение же тогда так и останется, Игроку нужно будет знать о карте. Тогда выходит, что я принесу тоже самое переделанное на 1 новый класс.

Это когда же на агрегацию такие ограничения наложили?


Игрок имеет ссылку на карту, но уже не является частью карты. Ты же знаешь о Земле, а ей плевать на тебя (образно говоря).

Ах да это верно, я продолжил думать, что Игрок остается частью Карты.

На счет агрегации, из Википедии

Ну вот я и предполагаю, что раз Гейм это контейнер и он агрегирует Карту и Игрока, то они должны существовать не зависимо от Гейма?

TGrey, нельзя так строго понимать утверждение из вики, в UML помимо агрегации есть только композиция, которая накладывает больше ограничений на ассоциацию. В общем, ничего страшного не будет, если Game создаст игроков.

Ну я так тоже и подумал, потому и писал везде Композицию, что раз, в моем случае, карта удаляется, то и Игроки тоже, а в этом случае Гейм удаляется, то и Карта с игроками тоже. Просто мне нужно указать точную связь и это же тогда Композиция выходит?

Композиция - это ближе к наследованию реализации, в нашем случае - агрегация.

Хмм, а можно не большой примерчик их отличия, потому что на консультациях преподаватель лично мне сказала, что раз при удалении контейнера сносится все содержимое, то это Композиция, если нужно будет им объяснить, что тут агрегация, то что говорить то)

первое попавшееся, но вроде по сути :
http://cssblast.ru/articles/oop_concepts/

К сожалению, там на самом интересном, статья не дописана и кода не хватает))
Но суть я понял такую:

Далее код и теория не соответствуют друг другу поэтому я полез в гугл найти не хватающей части, наткнулся на ту же википедию, но с довольно хорошим объяснением.
http://en.wikipedia.org/wiki/Has-a


Вот.

Я не хочу утверждать, что я прав или эта статья, просто хочу разобраться, как же оно на самом деле. Вот получается, что Game has a Map, has a Player.
Игрок не меняется на протяжении всей жизни Гейма, Карта по сути изменятся только внутри, а сам объект тоже остается неизменным на протяжении всей жизни Гейма.

Кстати тогда Player получается и Агрегирует Map. Т.к. он ее не создает, а просто "имеет" ее.

Это сообщение отредактировал(а) TGrey - 30.12.2010, 16:04