search

wolfenste / tictactoe

0 stars 0 forks source link

Remove `Player` #3

Closed flavius closed 6 years ago

flavius commented 6 years ago

I think you're better off if you remove the Player class. It doesn't have any value, and you can practice better TDD by forgetting about it - and start guiding your development with tests instead.

wolfenste commented 6 years ago

There are two Player classes to consider. The old one that resides in src directory and a new one that should help me to apply the algorithm I want. Maybe a new documentation .md file will help here. Moreover I feel if I do too much work in just one class (game class) the oop becomes useless. I do not want to do procedural programming with classes, right?

flavius commented 6 years ago

You don't know what you want to do. TDD is exploratory: as you write tests, you unveil structures/the architecture.

The point is to remove code whose construction was not guided by tests. You don't want to start with preconceptions about how the code should look. You want to start with a clean slate, listen to your client, document the business rules and write them down in integration tests (later we'll call them acceptance tests).

Whatever the result will be, it will be a reflection of the business in code.

That's what you want: to express business ideas, "the story", with code. It's called test-driven development for a reason.

Related:

image

It doesn't mean you won't have a class called Player. You most probably will. But you don't know yet what it will do.

flavius commented 6 years ago

Explore the domain, and develop it, with tests first.

wolfenste commented 6 years ago

Ok. I just hope I will be able to implement somehow my approach to find the winner. The player seemed to be perfect to carry that information.

flavius commented 6 years ago

In real life, a player can at most claim to be the winner, but some other party decides whether that is really the case or not.

Don't forget you're modelling the real-world. Yes, sometimes it's difficult, sometimes it makes sense to deviate from it, or to take shortcuts, but I doubt this is the case now.

Questions will arise while you design the system (while you write tests), and based on that we'll see what the result is.

You want to write code that anyone new to the project can understand: you tell them the story (the business rules), and with only that knowledge, they can map 1:1 the code to the story and the other way around.