Задача С Архитектура Вопрос - PullRequest
2 голосов
/ 06 июня 2010

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

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

Я установил класс "игрок", класс "фигура" и класс "доска". Фишка теоретически принадлежит как игроку, так и доске. Например, у игрока есть цвет, и каждый ход делает ход; так что игрок владеет своими фигурами. В то же время при перемещении фигуры она должна проверить, является ли она правильным ходом, есть ли фигуры на доске и т. Д.

Из моего прочтения мне кажется, что он неодобрительно относится к классам. Например, когда игрок делает ход, где должна жить функция, которая перемещает фигуру? Должен ли он существовать на борту? Это был бы мой инстинкт, поскольку правление должно решить, является ли ход действительным или нет; но кусок должен инициализировать этот запрос, так как он перемещается, нет?

Любая информация, которая поможет нубу, будет очень признательна. Спасибо, ребята!

Ответы [ 3 ]

2 голосов
/ 06 июня 2010

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

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

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

1 голос
/ 06 июня 2010

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

Класс для моделирования каждого игрока может не понадобиться вообще. Я бы начал с того, что класс доски управляет «состоянием» игры в нарды, а именно: чей это ход, если кости брошены, кости бросают, если необходимо, состояние всех 24 очков + бар + «выкл» «для каждого игрока - состояние куба удвоения, текущая длина матча и текущий счет для каждого игрока. (Я написал свою магистерскую диссертацию по нардам, включая программу оболочки командной строки для игр, поэтому я достаточно хорошо понимаю предметную область.)

@ Марк Бесси У меня, конечно, не было бы дизайна, в котором фигура (контролер) знает, как двигаться сама.

@ Felixyz Определить легальный ход в нардах немного сложнее, чем в шахматах. Это особенно верно, если вы хотите создать полный список законных ходов за каждый ход.

0 голосов
/ 06 июня 2010

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

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

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

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

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

...