2011-08-05 3 views
6

Я занимаюсь разработкой шахматной игры на Java (без ИИ, только с пользовательским управлением) и до сих пор привык к ООП. У меня есть два вопроса.Проектирование объектов для шахматной игры в java

Я имел в виду, имеющий, в дополнение к Game, Cell, Piece и Board объектов, в Player объекта.

Мой вопрос: мне действительно нужно? Конечно, мне это не нужно, но вариант считается лучшим вариантом? С одной стороны, кажется, что Player полезен для хранения информации об игроках и должен содержать такие методы, как takeTurn(). (Для моей реализации я также хочу отслеживать все возможные действия, поэтому у меня будет метод getAllMoves()). С другой стороны, разве игрок не просто реорганизация существующих данных? Каждая штука уже имеет указание, к какому игроку принадлежит. И поскольку моя игра не содержит ИИ, может быть смысл для takeTurn() принадлежать Game, а не Player. С другой стороны, возможно, Player может иметь только метод getAllMoves(), который использует свои данные, но не принимает меры.

Второй вопрос, релевантный, если ответ на первый вопрос - да, как я могу организовать отношения между объектами? getAllMoves() будет принимать в качестве входных данных массив ячеек; но странно, что тогда класс Player зависит от того, что его ячейки соответствуют (являются подмножеством), которые передаются в качестве входных данных. Было бы лучше, если данные с ячейками по-разному будут храниться вместе с массивом всех ячеек в Board и обновляться вместе, что гарантирует их согласие. Разумеется, гарантия, что они согласятся, будет существовать в любом случае, но, похоже, объект Player не должен знать о гарантии, имеющейся в объекте Board.

Как мне решить эти вопросы?

Спасибо!

+1

Звучит так, будто вы пытаетесь [BDUF] (http://en.wikipedia.org/wiki/Big_Design_Up_Front) - возможно, вы можете рассмотреть альтернативные способы изгнания вашей объектной модели, например [TDD] (http://msdn.microsoft.com/en-us/magazine/dd882516.aspx) – razlebe

+1

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

ответ

2

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

Для вашего второго пункта я не уверен, что Player должен непосредственно реализовать метод getAllMoves().

Я бы передал это объекту ChessGame. Игрок будет в этом случае есть ссылки на игры и делегатами getAllMoves называют к этому экземпляру игры, как это:

псевдокод :)

эй игры, какие ходы доступны для этой части ?

+0

Согласен. Имея getAllMoves внутри Player, он бы сделал всеведущим. Существует риск того, что такой подход приведет к накоплению логики внутри одного класса. В реальной жизни игрока можно рассматривать как оценку возможных ходов, глядя на доску. Это может быть транспонировано как сообщение, отражающее псевдокод, который вы указали. –

+0

Спасибо! Я думал, что у Игрока не должно быть ссылки на Игру, но я думаю, что это имеет смысл, что и есть. Еще одно место, где я спотыкаюсь, - это Piece. Кажется, что он должен хранить логику для разных ходов, доступных для разных частей, поэтому я создал класс для каждого типа штук. Но опять же, чтобы определить, может ли он двигаться, он должен знать о окружающих клетках. Это что-то, что игра или пьеса должна делать? – user64480

+0

@ user880129, это действительно хорошая вещь, чтобы задать себе этот вопрос, и я все еще теряю себя в таком виде рассмотрения. Когда-то ООП заставляет нас думать слишком много :) Для вашего дела я создам центральный класс, который будет действовать как хаб и сможет ответить на все вопросы, связанные с состоянием игры, например: эта ячейка свободна, что окружает ее, это перемещение вне доски, ... Так что в куске будет только описание движения и малая логика. Может быть, вы должны попытаться найти игру с открытым исходным кодом, чтобы посмотреть, как это делается. Это может помочь вам создать собственную систему. – Guillaume

1

Вопрос о том, нужен ли вам объект 'Player' - спросите себя, имеет ли этот объект какое-либо взаимодействие/отношения с другими объектами вашей системы. Кроме того, есть ли у вас какая-либо информация о данных или состоянии, которую вы, возможно, захотите записать? Я могу подумать о нескольких вещах, которые вы, возможно, захотите отслеживать, связанных с игроком - захваченные части, возможно, баллы очков.

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

+2

... имя игрока, цвет –

1

Вы знакомы с UML и более конкретно: диаграммы использования и последовательности операций; Это звучит как упражнение в моделировании, и было бы неплохо также взглянуть на понятие модели домена.

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

Этот класс системы может постепенно разлагаться при прохождении различных сообщений. Если метод/messsage не относится непосредственно к одному экземпляру класса и его атрибутам/внутреннему состоянию, скорее всего, он принадлежит где-либо еще (например: класс BankAccount не имеет такой же ответственности, как класс BankAccountManager). Вы можете группировать методы в соответствии с природой, и вы должны увидеть некоторые другие классы.

Оттуда должен быть простой случай определения того, существуют ли между ними отношения 1-к-1, один-ко-многим и многие-ко-многим. В Java они будут представлены единичными экземплярами или списками и направленностью (знает класс А о классе B или это улица с односторонним движением?) Представляется наличием или отсутствием ссылок внутри соответствующих классов.

P.S: Обратите внимание, что то, что я свободно описываю, - это подход к методологии, в то время как UML просто представляет себя с описанием системы из разных представлений.

Смежные вопросы