Я занимаюсь разработкой шахматной игры на Java (без ИИ, только с пользовательским управлением) и до сих пор привык к ООП. У меня есть два вопроса.Проектирование объектов для шахматной игры в java
Я имел в виду, имеющий, в дополнение к Game
, Cell
, Piece
и Board
объектов, в Player
объекта.
Мой вопрос: мне действительно нужно? Конечно, мне это не нужно, но вариант считается лучшим вариантом? С одной стороны, кажется, что Player полезен для хранения информации об игроках и должен содержать такие методы, как takeTurn()
. (Для моей реализации я также хочу отслеживать все возможные действия, поэтому у меня будет метод getAllMoves()
). С другой стороны, разве игрок не просто реорганизация существующих данных? Каждая штука уже имеет указание, к какому игроку принадлежит. И поскольку моя игра не содержит ИИ, может быть смысл для takeTurn()
принадлежать Game
, а не Player
. С другой стороны, возможно, Player
может иметь только метод getAllMoves()
, который использует свои данные, но не принимает меры.
Второй вопрос, релевантный, если ответ на первый вопрос - да, как я могу организовать отношения между объектами? getAllMoves()
будет принимать в качестве входных данных массив ячеек; но странно, что тогда класс Player зависит от того, что его ячейки соответствуют (являются подмножеством), которые передаются в качестве входных данных. Было бы лучше, если данные с ячейками по-разному будут храниться вместе с массивом всех ячеек в Board и обновляться вместе, что гарантирует их согласие. Разумеется, гарантия, что они согласятся, будет существовать в любом случае, но, похоже, объект Player не должен знать о гарантии, имеющейся в объекте Board
.
Как мне решить эти вопросы?
Спасибо!
Звучит так, будто вы пытаетесь [BDUF] (http://en.wikipedia.org/wiki/Big_Design_Up_Front) - возможно, вы можете рассмотреть альтернативные способы изгнания вашей объектной модели, например [TDD] (http://msdn.microsoft.com/en-us/magazine/dd882516.aspx) – razlebe
BTW Я думаю, что разработка игры, подобной шахматам, - очень хороший подход к знакомству с ООП. Помните, чтобы поддерживать ассоциаты через интерфейс по прямым подклассам, потому что последние создают жесткую связь, которая не всегда необходима. –