Help me please. I have a task:

  1. Making the game tic tac toe.

  2. Data output to the console in pseudographics.

  3. The user starts the game. Enter the coordinates of a point.

  4. Provide for the computer to start the game.

  5. Provide an increase field. The default field is 3 by 3.

  6. Provide for the complexity of the logic of the game. The one who collects 5 in a row wins.

Drew ULM:

UML for the game "Tic-tac-toe".

I know that nothing good, but I do not know yet how else ...

The most pressing questions in my opinion:

  1. Where can I store information about the games won?

  2. How to make a choice who for crosses who for tac toe?

  3. Any suggestions and constructive criticism from senior comrades. I would be very grateful.

Generally speaking, this task relates to object-oriented design, so I will be glad if someone offers interesting solutions, maybe not at all similar ...

  • one
    I do not see the point in the Move as an object. This is the state of the system. Draw another state graph - in which the system can be and what transitions are possible. - Nick Volynkin
  • one
    You also have confusion: desk (correct), desc, dasc. There is no need to treat a wrong move as an exception - just allow to put a mark only where it is possible. - Nick Volynkin
  • one
    As for the UML, it is safe to say one thing: when you start development, at least something will change, but rather 50 percent. Therefore, make a prototype, conduct reconnaissance in force. Then you will understand what structure should be. And be morally ready to throw out the prototype code and start over. - Nick Volynkin
  • one
    Где мне хранить информацию о выигранных партиях - the task does not say that it needs to be stored between the launches of the application. Just so you can store in a variable. Keep it simple) - Nick Volynkin
  • one
    I advise you to read the book "Clean Code" (Martin). Better - in the original, although it is possible and in translation. Bob Martin "Clean Code". It will help to move from the stage "I can write a working code" to "I write readable code." - Stepan

2 answers 2

I hate UML as a phenomenon, as an entity, as a product. In real life, I have not seen a single developer who would have designed something worthwhile on UML. UML is a cool tool if you need to push a poor student ** or fill up too much junior for an interview. Here is a hike, just the very case when the teacher decided to fill up the student :)

In real life, the agile approach works: when a construction is built in my head, a working layout is written based on this construction, then the construction is modified, then the layout is created again, modified again, and so on. When a construction becomes more or less sane, the UML design is already written and reported to the wise leadership, which UML primitives begin to rule with a clever look :)

In the end, everyone is happy and everyone laughs: the developer has a working prototype, a guide to the UML scheme, which is already implemented.

I suppose that here we have to go the same way: to begin the implementation of "tic-tac-toe" at the level of a common prototype with plugs instead of real steps and rendering. Then shift the resulting classes to the UML diagrams.

Update

And tell me how then to distribute a complex structure so that it is visually and conveniently? It is for yourself not to report?

Agile to help you: Any normal Java IDE makes it easy to write classes. Write classes immediately (that is, entities), without methods, but with fields. When classes are drawn, it will be more or less clear what to do with the methods. Then it turns out that either there are many classes, or there are not enough of them, you are iterating. After a couple of iterations, everything will become clear. If the iterations are more than 3-4, then you have not yet understood the task - sit, have coffee, smoke, meditate, and again on the new one. When it clears up with methods, you can begin to abstract - enter interfaces, abstract classes, all sorts of patterns, and so on.

  • I was surprised by your response and reaction to it. You say UML is not needed by the developer. And how to write if the application was not tic-tac-toe, and had 50 classes? Somehow you have to imagine at least as a whole how it will be. - Pavel
  • one
    UML is needed as a documentary tool, but not as a design, I tell you as a person with programming experience from a time when 4k RAMs were a luxury :) - Barmaley
  • And tell me how then to distribute a complex structure so that it is visually and conveniently? It is for yourself not to report? So you can figure out how it will be? What to use? - Pavel
  • 2
    UML is a great design tool, I tell you as a person who hasn’t been holding a pen or pencil in his hands for 5 years - Pavel Mayorov
  • see the answer update - Barmaley

Your classes have blurry responsibilities.

Take the class Desc. What is he doing at all? Creates and stores a matrix of rows? ..

There is such a rule - Tell-Don't-Ask . You do not need to ask the board for its condition in order to process it - you must order the board to do this processing!

Of course, one day you will still have to pull the matrix out of the board, for processing by the same bot. But it is necessary to prepare it as much as possible! For example, why does the bot know by crosses or zeros he plays? It is not absolute colors (cross-toe) that are important to him, but relative (friend-foe) colors. This is the transformation the board should do.


Position class has too many responsibilities. He keeps the player's turn - and he reads it! It is not right. Reading should remain inside User / UserInput (by the way, why are they separated at all?) - and Position (which would be more correct to call Move) should have only 1 responsibility.

By the way, why is the character stored in Position? The player that can choose crosses or zeroes, he makes another move? :)


Now about the Game class. He again has two responsibilities - he determines the winner (for which the board gives him his inner state!), And watches the game. Do not do it this way. Let the winning position be determined by the board, thus being the only point of expansion.

Why does the game distinguish between a human player and a bot player? How does the game matter who plays it? Are you not looking at the game of two bots? And why did you even make them a common interface, if the game still accesses them separately? A game must distinguish between a player playing crosses - and a player playing zeroes. And who among them is a man - no one has interesting details!


And the last. You have neither the user nor the bot have access to the current position. Is this what is intended? :)

  • one
    Classes should be small and their responsibilities should be very limited. The principle of "who creates the data and processes it" is very doubtful. It turns out that in Word the class that stores / reads the data should display and check them for spelling? - Stepan
  • 2
    @Stepan no, it should not. But definitely the class responsible for spelling should also not save and load. - Pavel Mayorov
  • one
    @Pavel 1) oh well. Cross is your own or someone else's? - Pavel Mayorov
  • one
    @Pavel 2) Position is a typical DTO. This rule is not applicable to DTO. - Pavel Mayorov
  • one
    @Pavel 3) what difference does it call move () directly or via the interface - if you have user and bot variables? - Pavel Mayorov