Кому должен принадлежать метод?

Question

Я пытаюсь разработать простую игру - Понг, Арканоид - используя строго «Правильный ОО», что бы это ни значило.

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

Кто должен заниматься, например, коллизиями? И счета?

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

И это слишком много для бедного мяча.

Answer 1

эмпирическое правило:

• если объект логически владеет всем задействованным состоянием, то он владеет методами, которые используют это состояние
• если метод требует состояния из более чем одного объекта:
  • если объект-контейнер владеет всеми объектами, используемыми методом, то он также владеет методом
  • в противном случае вам необходим объект 'bridge' для владения служебным методом
  • , если не существует веского аргумента в пользу того, что один объект является «контроллером» для метода (хотя и не могу придумать пример от руки)

в вашем случае «игровая доска» или «игровая среда», вероятно, будут иметь класс (или группу методов) «физика игры», которому принадлежат методы обнаружения столкновений (утилита / мост)

Answer 2

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

Таким образом, для обнаружения столкновений у вас может быть класс CollidingElement, который обрабатывает положения и формы. Затем этот объект может быть встроен композицией в любой объект, который должен столкнуться в игре, и делегировать ему любой необходимый вызов метода.

Answer 3

Хороший или плохой дизайн проявляется в том, насколько хорошо он соответствует неожиданным требованиям, поэтому я бы посоветовал держать запас потенциальных «игровых функций» под рукой, чтобы сообщить о своих дизайнерских решениях. Поскольку вы делаете это как учебный проект, вы можете позволить себе сойти с ума.

Арканоид - очень хороший выбор для этого, он предлагает так много вариантов. Заставьте разные кирпичи набирать разное количество очков. Сделайте несколько кирпичей изменить счет других кирпичей при попадании. Сделать несколько кирпичей, требующих нескольких попаданий. Дайте суперспособности мячу, веслу или кирпичу. Изменяйте эти способности: одна из них делает шарик управляемым с клавиатуры, другая делает его прозрачным, другой меняет направление на гравитацию и так далее. Заставьте кирпичи бросать предметы.

Цель состоит в том, чтобы при внесении такого изменения оно влияло на минимально возможное количество классов и методов. Узнайте, как ваш дизайн должен измениться, чтобы соответствовать этому критерию.

Используйте интегрированную среду разработки, в которой есть меню «Рефакторинг», в частности, метод перемещения рефакторинг. (Если нет, прочитайте книгу Рефакторинг .) Поэкспериментируйте с размещением различных методов здесь и там. Обратите внимание, что становится трудно изменить, когда метод помещен «неправильно», и что становится легче, когда вы размещаете его в другом месте. Методы размещаются правильно, когда объекты заботятся о своем собственном состоянии; Вы можете «сказать» объекту, чтобы он что-то сделал, вместо того, чтобы «задавать» ему вопросы о его состоянии, а затем принимать решения на основе его ответов.

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

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

И так далее ...

Answer 4

Это действительно зависит от вашей реализации, но я думаю, что у вас будет объект «игровой доски» для управления ведением счета, или, возможно, объект цели на каждой стороне. Что касается столкновений, я думаю, вы можете передавать события между объектами. Я думаю, что любой объект должен знать свое местоположение.

Answer 5

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