Java – the simplicity of OO for user interaction

As a summer project, when I have some uni downtime, I'm going to build a monopoly game This question is more about the general idea of this problem than the specific task I want to perform

I decided to build this from the bottom up, create the motion around forty space plates, and then continue to interact with space I realized that I wasn't sure the best way to deal with this problem, and I was torn between two design ideas:

>Give each space its own object, all subclasses of a space object, so that the interaction can be defined by the space object itself I can do this by implementing different land () methods for each type of space. > Only give properties and utilities (each property has a unique function) objects and create methods to deal with the purchase / lease in the main class of the program (or the motherboard I am calling) Spaces such as super tax can be checked by a small group of conditions to see if the player is in a special space

Option 1 is obviously the way OO (and I think it's right) does things, but I just want to deal with user interaction from the main class of the program In other words, I don't want space objects to interact with the player Why? Errr. So far, I have done a lot of coding, which is very simple, but I don't know whether it is a pipe dream for large projects Should I really handle user interaction in a completely separate class?

As you can see, I'm confused about this situation Is there any way? Moreover, does anyone have any suggestions on practical OO design that can help the general public?

Editor: as I noticed, I think I lost a little attention on this issue I'm interested in the general approach of really combining OO with any external action (command line, network, GUI, file management, etc.)

Solution

Finally, it's up to you That is the beauty of OO, because it is explained There are usually some patterns to follow, but in general, your decision how to deal with it

However, you should carefully consider that each actor in the system should know the rest Does the property really know players, account balances and other players? Probably not Property should know its cost, rent, etc

On the other hand, should the main clue care about trifles such as rent? Probably not Its main concern should be the state of the game itself, such as dice rolling, whether each player wants to trade or buy or improperly mortgage, and so on

Think about the action of boarding the square Once logged in, players have three options:

>Buy property > ignore this attribute > pay rent

Now, which role in the system knows all the information needed to do this We have a game class and don't care about such trouble We own property and we don't care about the players But the player object knows all this information It keeps records owned by each player and can easily access the correct data

So, if it were me, I would make a player Performmove (die d) method It has easy access to accounts This also allows minimal coupling between classes

But in the end, it's up to you I believe people have created monopoly clones in perfect OO and functional or programming languages Finally, use what you know and keep refactoring until you are satisfied with the final design