Liutauras Vilda

It looks like an Excel. Why do you need to write it in Python if you got your data in Excel sheet already? Can't you calculate using an existing supported formulae?

For me to use a fairly simply project for practising is like asking someone to explain a complicated concept in simple words.

"I know it is complicated, can you try to explain it in simple words please?"

Those who did not read yet, read a book (recommended by Junilu multiple times. I read 4-5 times, probably will read 6th soon) "Understanding the 4 Rules of Simple Design by Corey Haines", and you'll be surprised how much insights one can put into one, yet simple line of code. It is like to polish a crystal glass which looks shiny already.

Junilu Lacar wrote:I was in an ensemble practice session at work yesterday and someone in the group made an interesting comment about this line:
game.makeAMove();
The comment was along the lines of "I think it's weird to tell the game to make a move. I think we should tell a Player to make a move."

Any thoughts on this? How would you respond?

Thought is interesting and worth stopping by.

For me is also interesting that everyone is thinking how the method name could be changed to better reflect the intent. But what if an actual variable name upon method is called isn't descriptive enough?

If it were:
tictactoe.makeAMove()Does it feel the same as if it were game?

tictactoe in this context may mean an Actor, whether a human player or computer.

Junilu Lacar wrote:@Nested class Game_starts {    @Test    void with_an_empty_board() {        assertThat(game.board()).isEqualTo(BLANK_BOARD);    }    @Test    void with_X_making_the_first_move() {    } } @Nested class Game_ends {    @Test    void when_somebody_wins() {    }    @Test    void when_its_a_draw() {    } } @Nested class Player_wins {    @Test    void when_they_complete_a_row() {    }    @Test    void when_they_complete_a_column() {    }    @Test    void when_they_complete_a_diagonal() {    } }

I find those tests very likeable. I'm going to try to see how my code changes if those tests drive my design.


Up until now I was doing my experiments there: https://github.com/liutaurasvilda/tic-tac-toe

Hey Junilu, enjoying to read! Apologies for not participating as you may would expect.

One question, is it inline with TDD practice, that like you say, sketch out first, meaning design test(s) headlines, then unimplemented methods, and then when you have some minimal coherent story (you decide yourself when), then you implement them?

Or you have to strictly go [1] write a failing test, [2] make test pass, [3] refactor, [4] write another failing test, ...?

I did some sketching on my end, and found it to be a good proxy into actually practicing TDD, because somehow found it a bit easier to go about that way than strictly write a failing test, make test to pass, refactor it, write another failing test...

Junilu Lacar wrote:Here's one question I would ask:

Between hasLegalMoves() and boardAllMarked which one is more aligned with intent rather than implementation?

Well, I agree with you to some good extent. While boardAllMarked() literally means what is exactly happening, but yes, it is sort of representing an idea at a lower abstraction.

Taking about the abstraction, hasLegalMoves() or availableMoves() are so abstract, along with other your demonstrated code, that you almost could reuse its structure as is (of course with different low level impl) in some other game, not even necessarily played on the board. So it is very interesting.

Thanks Junilu, very useful insights.

And no, TDD is not easy, which seems to be conceptually a trivial thing, practically is very difficult.

I find myself constantly consulting myself with my just previously written code, so I could think about the next needed step to take, so I could write a next test first.

I'm not even sure if after few/several years of not practicing it you can actually convert your habits. Probably it takes way more effort than it would take for some other habit to change.

It is very weird feeling, I feel that I very well envision and understand the value of practicing TDD, but yet, couldn't make it in practice.

A bit philosophical...

I'm thinking now about the legalMoves or availableMoves here.

In chess seems natural to think about the moves, because figures are moving from one location in the board to another.

Over here, nothing moves nowhere. Players i.e. just marking the board.

But perhaps that word "moves" is a bit ambiguous in general when used in the sentence.

Junilu Lacar wrote:private boolean isDraw() {   return hasNoWinner() && hasNoLegalMoves(); } private boolean hasNoLegalMoves() {   return legalMoves().isEmpty(); }

Regarding the legal moves... That implies to me, that there are some illegal moves as well, however, we are just not dealing with them here (for now..).

For me personally:
private boolean isDraw() {   return hasNoWinner() && boardIsAllMarked() }Adds a bit more clarity what's potentially going on behind the hoods. Doesn't that mean code is better readable?

What about availableMoves()?

What are your thoughts?

Junilu Lacal wrote:@Test void new_game_is_in_play() {   TicTacToe game = new TicTacToe();   assertTrue(game.isInPlay()); }

If I would need to understand the rules, I would ask someone (in addition to How the game is played in general):
- When the game is considered finished?
instead of
- When the game is considered still in play?

What your thoughts on that? Because that question describes the exact condition(s) when the game is finished and hence what needs to be coded in.

I personally like more (at the moment) game.isFinished()

https://adventofcode.com/

Tim C. I have problems with patience.

Are we going to have usual suspects?

Sukoluhle Ndlovu wrote:Below is an java application called Hospital Inspection GUI

Interesting aspect how you are calling your application, by adding GUI to its name. That is potentially part of the reason why you think you should start from GUI implementation, because that means to you an application.

Similarly like my Mom calls a monitor a computer. "This computer is big".

GUI stands for graphical user interface. Other type of interface could be a CLI - command line interface. So as you noted word interface twice, that suggests it is just an interface, how user interacts with an application. So when you implement a main application logic, then you can attach UI (user interface) whether it be a Graphical or Command line.

And your starting object which could hold (encapsulate) the information you need may look as:
final class Hospital {    private final String name;    private final String location;    private final int yearsSinceInspection;        public Hospital(String name, String location, int yearsSinceInspection) {        this.name = name;        this.location = location;        this.yearsSinceInspection = yearsSinceInspection;    } }You'd need to add getters as appropriate and maybe override toString() method.
Or using more recent Java version, you could write this class as a record:
record Hospital(String name, String location, int yearsSinceInspection) { }
So, a number of Hospital objects may go to an array or other data structure to hold them, but that you can decide when you get to that point.

I agree, UI just adds noise at this stage and does not help to solve an actual problem. To rephrase that: "You are illustrating a book cover without knowing what content it may contain". Book cover supposed to communicate the content of the book in some sense, so you need to write a book first. You can make that cover later.

Welcome to the Ranch