我被教导不要将大多数方法放在通用的“系统”类中，而是将它们放在哪里？

Question

I'm making a game. It seems most natural to put almost all the game logic in the Game class, have it create all the objects and have mostly getters and setter methods in them. Is this actually wrong? Should I try to force some of the game logic into the other classes like the process of Player taking his turn as a method of Player ?

In a typical game, if a player shooting is triggered by a mouse click, how would you go from the click event to updating the screen state to destroying the target object in terms of where the methods would be located and objects calling each other?

Should I even be getting rid of the Game class and somehow having the other objects all calling each other?

Answer 1

How long term is this project? If you planning a long term project, there is a pretty decent chance that you will eventually want to jettison your hand-coded UI and integrate with one of the big Java game-graphics engine instead.

If this assumption is true, you might want to use the Model View Presenter pattern , to make it easier to port your graphics library, along with the other benifits of MVP (modularity, testability, leaps over tall buildings, etc.)

So, if you go down this path, you would have

• GameModel: The data used in your game.
  • May/May not have Player etc. classes along for the ride.
  • Code to save/load/track players should be in this layer.
• GamePresenter, which contains all your UI logic
  • It knows about the GameModel and associated classes.
  • It may pass events to the GameView, either using event handlers or defining a IGameView interface. It may not however, know any details of how the real GameView is implemented.
• GameView
  • It knows all about the GamePresenter and GameModel.
  • It should only have the code needed to actually display your game and get input back from the user.

Answer 2

The way you describe the problem reveals that you are overloading the class Game with logic that should belong in other objects.

The first signal appears when you say that other objects "have mostly getters and setters". That means that those objects are just data structures holding state but lacking interesting behavior. This indicates that you still have to think deeper on how you distribute responsibilities among objects.

The second evidence is in the second paragraph of your question. It suggests poor separation between model and GUI. A good test to verify whether there is adequate separation (or not) is to prove that you could play the Game (at least non-trivial parts of it) from a script, ie, without exercising any GUI code. The game model will only be properly designed if it is full functional in "headless" mode.

Finally, getting rid of the Game class would be a bad decision because your model would not have any representation of an entity that exists in the "reality" you are trying to model.

I think that the Game -centric design you describe reflects your way of looking at the domain. If you only see "the game" you will model just that. However, games are usually rich simulations full of interesting objects whose behaviors go far beyond their interactions with the player. I would therefore recommend more thinking on the other objects, what they know, what tasks could they carry on, how would they collaborate with others, etc. In other words, do not program the game, program its actors, elements, rules, stages, strategies, characters, etc. Do not underestimate any entities either; all of them have something interesting to add to the whole, even a single tile in the chess board has something to contribute to the small universe you are creating. Not something that anybody else could provide, something that no other object could provide with economy of code and elegance.