OO по сравнению с Простотой когда дело доходит до взаимодействия с пользователем

Я согласен, вариант №1 кажется лучше.

Насчет «взаимодействия с пользователем» - все зависит от обстоятельств. Вы можете оставить часть своего кода в другом классе. Например,

// in main class
user.landOn(space);
if (space.containsProperties()) doSomething(); // Option #1 for some user-interaction code

// in User.java
public void landOn(Space s) {
    // do some checks
    s.land(this);
    if (s.containsProperties()) {...} // Option #2
    // something else?
}

// in GetMoneySpace.java
@Override
public void land(User u) {
    u.awardCash(200);
    // Option #3 - no properties so nothing here
}

Это гораздо больше ООП (и, на мой взгляд, лучше), чем что-то вроде

if (space.isCashAwardSpace()) {
    user.awardCash(space.getAward());
}
if (user.something()) doSomething(); // Some user-interaction code

Использовать первый дизайн. У вас будет класс Property и подкласс специальных свойств, переопределив поведение по умолчанию.

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

Примеры классов:

• Свойство
  • имя
  • цена
  • baseRent
  • houseCount
  • hotelCount
  • ипотека
  • getCurrentRent ()
• RailRoad расширяет свойство
• Утилита расширяет свойство
• Board
  • свойства
• Пользователь
  • токен
  • playerName
  • currentProperty
  • ownProperties
  • buyProperty ()
  • payRentOnProperty ()
  • mortgageProperty ()
  • move ()

Одной из задач объектно-ориентированного проектирования является упрощение представления проблемы в пространстве решений (т. Е. Моделирование системы на компьютере). В этом случае рассмотрите отношения между объектами. Достаточно ли функциональности в пространстве , чтобы гарантировать его абстрагирование в класс, или имеет смысл иметь дискретные классы Свойство и Утилита , не связанные с Пространство из-за уникальных особенностей обоих? Является ли свойство особым видом пространства или просто полем в пространстве ? Это те проблемы, с которыми вам, вероятно, придется столкнуться при разработке игры.

Что касается взаимодействия, то, как правило, плохие новости для дизайна, когда у вас есть « класс бога », который выполняет всю работу и просто запрашивает информацию у других классов. Есть много способов попасть в эту ловушку; один из способов определить, имеете ли вы дело с божественным классом, - это найти имя класса, включая Manager или System .Таким образом, вероятно, не лучшая идея иметь своего рода «игровой менеджер», который запрашивает данные у всех других объектов, вносит все изменения и все отслеживает. По возможности устраните их.

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

Очевидно, вы можете сделать это разными способами, но мой дизайн будет примерно таким (итерация определенно может доказать, что это неверно):

• Space класс, содержащий базовые данные и методы, общие для все клетки (например, их положение на доске, занято или нет и т. д.).
• Подклассы перемещаются от наиболее распространенных ( Свойство и Утилита ) к наиболее уникальным ( Go , Jail , FreeParking и т. Д., Вероятно, одиночные) с полями и методами, связанными с каждым из них.
• Класс Player , содержащий информацию об игроке.
• GameState класс, связанный с состоянием игры; чья очередь, сколько домов осталось в банке и так далее.

Удачи вам в игре и продолжении учебы.

Естественно, Google - ваш друг, но вот несколько примеров, которые я бы порекомендовал прочитать:

• Моделирование банкомата (эта идея также обсуждается в Ребекке Книга Вирфса-Брока ниже)

• Эвристика объектно-ориентированного дизайна - Артур Рил

• Чем отличаются дизайны (PDF), Разработка объектно-ориентированного программного обеспечения - Ребекка Вирфс-Брок

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

Я бы выбрал ваш первый подход. Он инкапсулирует поведение там, где это необходимо. Итак, у вас были бы подклассы Space для Utilities, Properties, GotoJail, FreeParking - в основном всех различных категорий пространств. Что группирует категорию, так это обычное поведение.

Ваши пространства свойств могут сами иметь объект группы в качестве члена, например чтобы сгруппировать все темно-синие свойства вместе.

Что касается взаимодействия с пользователем, вы передаете экземпляр Board (или, лучше, GameController) каждому пространству, чтобы он знал, частью какой игры он является, и мог влиять на игру. Затем пространство может вызывать определенные действия на доске, такие как перемещение фишки, задание вопроса пользователю и т. Д. Главное, что существует разделение - взаимодействие с пользователем не происходит внутри каждого пространства, но пространству разрешено попросите, чтобы произошло какое-то взаимодействие или чтобы кусок переместился. Ваш GameController должен фактически выполнять взаимодействие или перемещать элементы и т. Д. Такое разделение упрощает тестирование, а также предоставляет альтернативные реализации по мере необходимости (например, разные правила игры в разных редакциях / странах?)

Вариант 2 не имеет особого смысла, или, по крайней мере, он не так понятен мне, как вариант 1. В варианте 1 вам не нужно обрабатывать взаимодействие с пользователем внутри вашего космического объекта. Вы можете иметь в своем основном классе или отдельном классе отдельный класс, предназначенный для обработки взаимодействия с пользователем:

public void move(Player p, int spaces){
    Space landingSpace = board.getLandingSpace(p,spaces);
    landingSpace.land(p); //apply your logic here
}

Как вы можете видеть, класс Space отвечает за проверку Player p, который собирается приземлиться на это пространство. Он применяет любую пользовательскую логику, проверяет, достаточно ли у него денег, является ли это чем-то, чем владеет игрок, и т.д. Каждый подкласс Космос будет иметь свой собственный набор правил, как вы описали в варианте 1.