Thiết kế các đối tượng cho trò chơi cờ vua trong java

Question

Tôi đang thiết kế trò chơi cờ vua bằng Java (không AI, chỉ do người dùng kiểm soát), và vẫn quen với OOP. Tôi có hai câu hỏi.

Tôi đã nghĩ đến việc có, ngoài các đối tượng Game, Cell, Piece và Board, đối tượng Player.

Câu hỏi của tôi là, tôi có thực sự cần phải không? Tất nhiên tôi không cần, nhưng là một trong hai lựa chọn được coi là thiết kế tốt hơn? Một mặt, có vẻ như một Người chơi rất hữu ích để chứa thông tin về các phần của người chơi và nên chứa các phương pháp như takeTurn(). (Để thực hiện của tôi, tôi cũng muốn theo dõi tất cả các động thái có thể, vì vậy tôi sẽ có một phương pháp getAllMoves()). Mặt khác, không phải là Player đơn giản là sắp xếp lại dữ liệu hiện có? Mỗi mảnh đã có một dấu hiệu của người chơi mà nó thuộc về. Và vì trò chơi của tôi không chứa AI, điều này có thể có ý nghĩa đối với takeTurn() thuộc về Game, thay vì Player. Mặt khác, có lẽ Player chỉ có thể có phương thức getAllMoves(), sử dụng dữ liệu của nó nhưng không thực hiện hành động.

Câu hỏi thứ hai, có liên quan nếu câu trả lời cho câu hỏi đầu tiên là có, là làm cách nào để tổ chức các mối quan hệ giữa các đối tượng? getAllMoves() sẽ lấy đầu vào như một mảng ô; nhưng nó cảm thấy lạ khi lớp Player phụ thuộc vào thực tế là các tế bào của nó khớp nhau (là một tập hợp con) các ô được truyền vào như đầu vào. Sẽ cảm thấy ổn hơn nếu dữ liệu được chia theo từng ô sẽ được giữ cùng với mảng của tất cả các ô trong Bảng và được cập nhật cùng nhau, do đó đảm bảo rằng chúng đồng ý. Tất nhiên, sự đảm bảo rằng họ đồng ý sẽ tồn tại một trong hai cách, nhưng có vẻ như là đối tượng Player không nên nhận thức được sự bảo đảm đang diễn ra trong đối tượng Board.

Làm cách nào để giải quyết các câu hỏi này?

Cảm ơn!

Answer 1

IMHO có đối tượng Trình phát là thiết kế tốt.
Bạn thậm chí có thể tinh chỉnh nó sau này thành giao diện có cài đặt AIPlayer và HumanPlayer.
Hôm nay, bạn chỉ cần phương thức getAllMoves nhưng sau này bạn có thể cần thêm. Có một đối tượng sẽ giúp bạn mở rộng khả năng phát của người chơi.

Đối với điểm thứ hai của bạn, tôi không chắc rằng Trình phát sẽ thực hiện trực tiếp phương thức getAllMoves() hay không.

Tôi sẽ ủy quyền cho đối tượng ChessGame. Người chơi sẽ trong trường hợp này có một tham chiếu đến các trò chơi và các đại biểu các getAllMoves gọi để dụ game này, như thế này:

pseudo-code :)

hey game, di chuyển có sẵn cho mảnh này là gì ?

Answer 2

Câu hỏi liệu bạn có cần đối tượng 'Trình phát' hay không - hãy tự hỏi liệu đối tượng này có bất kỳ tương tác/mối quan hệ nào với các đối tượng khác trong hệ thống của bạn hay không. Ngoài ra, nó có bất kỳ dữ liệu hoặc thông tin trạng thái nào mà bạn có thể muốn ghi không? Tôi có thể nghĩ về một vài điều bạn có thể muốn theo dõi liên quan đến một cầu thủ - những mảnh bị bắt, có thể là một điểm số.

BTW có thể là một ý tưởng tốt để xây dựng mô hình đối tượng để trực quan hóa cách các đối tượng liên quan với nhau. Điều này cũng sẽ cung cấp cho bạn một ý tưởng tốt hơn về các giao diện giữa các đối tượng và các phương thức được yêu cầu.

Answer 3

Bạn có quen thuộc với UML và cụ thể hơn với biểu đồ Trường hợp sử dụng và Trình tự không? Điều này nghe có vẻ như một tập thể dục trong mô hình hóa và nó sẽ là một ý tưởng tốt để cũng tìm kiếm khái niệm về mô hình miền.

Sử dụng các diễn viên trong trường hợp như Trình phát thường được chuyển thành các lớp (còn gọi là thay thế). Các lớp khác có thể được xác định bằng cách bắt đầu với một sơ đồ tuần tự thô cho từng trường hợp sử dụng với lớp diễn viên của bạn ở một bên và lớp hệ thống toàn cục ở một bên.

Lớp Hệ thống này có thể bị phân hủy dần khi bạn đi qua các thông báo khác nhau. Nếu một phương thức/messsage không trực tiếp đến một cá thể của một lớp và các thuộc tính/trạng thái nội bộ của nó có thể là nó thuộc về nơi khác (ví dụ: một lớp BankAccount không có cùng khả năng như một lớp BankAccountManager). Bạn có thể nhóm các phương thức theo bản chất và bạn sẽ thấy một số lớp khác xuất hiện.

Từ đó trở đi sẽ là một trường hợp đơn giản để xác định xem có bất kỳ mối quan hệ 1-đến-1, một-nhiều và nhiều-nhiều nào giữa chúng hay không. Trong Java, chúng sẽ được biểu diễn bằng các cá thể đơn hoặc Danh sách và hướng (lớp A biết về lớp B hay là một đường một chiều?) Được thể hiện bằng sự hiện diện hoặc vắng mặt của các tham chiếu bên trong các lớp tương ứng.

P.S: Lưu ý rằng những gì tôi mô tả lỏng lẻo là một cách tiếp cận phương pháp trong khi UML đơn giản là nội dung chính nó với mô tả một hệ thống từ các quan điểm khác nhau.