У меня есть некоторые объекты, которым требуется два типа поведения одновременно, когда они связаны с игровым классом. Как лучше всего это сделать? Я не вижу здесь никаких шаблонов GoF, которые могли бы помочь, но, возможно, я просто перегружен своим мозгом.
interface Actor {}
class Man implements Actor {}
class Woman implements Actor {}
class Game {
private Map<Actor> actors;
}
Как включить поведение Player, Referee или LineJudge в этот код?
Пример:
Игра 1, Актер 1, Женщина и Судья, Актер 2, Женщина и Игрок
Игра 2, Актер 1, Женщина и Игрок, Актер 2, Мужчина и Игрок
Игра 3, Актер 1, Мужчина и Игрок, Актер 2, Мужчина и Рефери, Актер 3, Женщина и Судья на линии
...
Не могли бы вы уточнить требуемое поведение? Например, мужчина-арбитр ведет себя иначе, чем женщина-арбитр? Могли бы вы иметь атрибут «секс» со значениями «Мужчина» и «Женщина» вместо двух отдельных классов «Мужчина» и «Женщина»? Могли бы вы иметь три отдельные коллекции для игроков, судей и линейных судей в классе Game вместо одной коллекции «актеры»?
Два типа поведения одновременно? Вы имеете в виду с точки зрения полиморфизма? Или просто разные операции?
@ThomasKilian У меня есть диаграмма UML, но я не могу загрузить ее из-за ограничений сайта. Да, у меня есть интерфейс, но для мужчины и женщины, которые на самом деле ведут себя по-разному, но находятся в одной группе. Мне нужно добавить также другой тип.
@muszeo Да, два типа поведения (классификация) одновременно. Быть игроком-женщиной или игроком-мужчиной — это не одно и то же. Различные операции.
@www.admiraalit.nl да, рефери-мужчины ведут себя не так, как рефери-женщины. Я мог бы указать поведение1 и поведение2 в качестве атрибутов, но я хочу сделать хороший дизайн. Да, я думал о трех коллекциях в Class Game, но не знаю, лучшая ли это, поэтому и прошу совета. Спасибо!
Поведение – это делать что-то определенным образом. Все несупертривиальные классы имеют более одного поведения.
Есть несколько возможных решений. Я приведу варианты, которые, по моему мнению, скорее всего будут соответствовать вашим требованиям, но есть и другие возможные решения. Что лучше в вашей ситуации, зависит от конкретной функциональности, которую вам нужно реализовать.
Вы можете определить класс Актер с двумя атрибутами: один типа Person, который может быть мужчиной или женщиной, и другой типа участника, который может быть игроком, рефери или линейным судьей.
Вместо одного вы можете определить три набора Актеров в классе Game, по одному для каждой роли, которую актер играет в игре. Ну, если есть только один рефери, то это не совсем коллекция.
@ www-admiraalit-nl это похоже на наличие класса ассоциации между актером и игрой?
@thefloki, Нет. Связь между Актером и Человеком (композиция с кратностью = 1) эквивалентна атрибуту типа Человек в классе Актер. Точно так же связь между Актером и Участником эквивалентна атрибуту типа Участник в классе Актер.
Вы должны удалить агрегаты, поскольку они касаются времени жизни объектов. И это просто не имеет значения в данном контексте.
@ThomasKilian, спасибо, игра не должна объединять актеров, это верно. Однако на первой диаграмме Актер представляет собой композицию из двух объектов, Человека и Участника. В моем предложении экземпляр Актера инкапсулирует данные и поведение одного Человека и одного Участника. Всякий раз, когда Актер получает вызов метода, он делегирует поведение одному из своих компонентов, где это уместно. Это альтернатива подклассам Актеров с именами ManPlayer, WomanPlayer, ManReferee, WomanReferee и т. д.
Звучит разумно. Увы, это просто основа для обсуждений на доске ;-) В любом случае, я проголосовал за закрытие вопроса, поскольку ОП использует термин «поведение», не имея представления, что он на самом деле означает.
спасибо вам обоим! приму во внимание ваши советы.
В вашем коде уже скрывается интерфейс. Так в чем проблема? И пока вы помечаете этот UML, почему вы придумываете код?