Эта диаграмма - хорошее начало, но многое еще предстоит сделать. Я обращу ваше внимание на некоторые моменты, которые вам нужно улучшить, но не мешая вам учиться на практике.
Сначала некоторые формальности:
- используйте стрелки только для связи, чтобы указать навигационность . Если ссылка двунаправленная, используйте 2 стрелки или ни одной. Например, здесь мы могли бы понять, что
View знает ChessBoard, но не ясно, если ChessBoard знает о Views: как ChessBoard может сообщить Views, что состояние платы изменилосьпосле того, как движение было сделано? - указывает кратность : например, мне интересно, если это один
ChessBoard для одного View или может быть несколько Views для одного и того же Chessboard? - Избегайте неоднозначности между ассоциациями и свойствами. Например, в
View у вас есть свойство model типа ChessBoard. Но у вас также есть связь с ChessBoard. Так это все же ChessBoard? Или у нас есть два ChessBoard s, один связанный и один встроенный? Было бы яснее удалить model из свойств и указать model в качестве имени ассоциированного объекта на конце ассоциации . - Ассоциация, начинающаяся с
Controller, которая внезапно распадается на две части, не очень практична, особенно если вы расскажете нам о целях и множественности ассоциаций. Предпочитаю визуально иметь две очень четкие линии.
Теперь до сути:
- Ваша модель должна быть не просто
ChessBoard. Модель должна быть Game, которая имеет пару элементов. ChessBoard - только один из них: текущая позиция Piece с. Но как насчет layers? Где они ? Откуда мне знать, что их двое? Откуда Контролер узнает, что это за ход? - Называя что-то
ChessBoard, которое больше, чем шахматная доска, вы можете создать путаницу. Например, может ли доска знать наверняка, если isGameOver(), просто с информацией о положении фигур? Разве не возможно, что игрок решает отказаться? Поэтому постарайтесь назвать ваши классы в соответствии с тем, что они действительно представляют. - Как я могу узнать, какие
Pieces находятся на доске? - Откуда мне знать цвет
Piece? - Как я могу узнать, свободна ли ячейка доски?
- Что произойдет, если фигура будет удалена с доски, потому что она была взята?
Ваша UML-диаграмма должна развиваться, чтобы прояснить все это. Поэтому я думаю, что для завершения ChessBoard и Piece вам не хватает как минимум Game, Player, BoardCell (также называемый ""Квадрат", и некоторые контейнеры Pieces perhap все еще находятся на доске для каждого игрока.
После того, как вы закончите, вам также нужно подумать о связи между моделью, видом иКонтроллер, чтобы быть уверенным, что контроллер знает достаточно, чтобы давать команды модели, но также и то, что модель может информировать View, когда что-то изменилось.
PS: я добавил несколько ссылок на Chess Programming Wiki , так как этот сайт хорошо описывает некоторые элементарные концепции для программирования игры, некоторые обычные вопросы , а также множество ссылок. Однако имейте в виду, что этот ресурс очень информативенне очень объектно-ориентированный.