My idea basically what i am thinking so far is using the playerTurn boolean and set it to false if its player ones turn and true if it is player twos turn.
Junilu Lacar wrote:You could also just use reference equality. Since you only have two players, then this code should work:
IMO, this is more straightforward and reads better.
Junilu Lacar wrote:One problem I have with a Boolean variable named playerTurn is that it doesn't make any grammatical sense. Code that doesn't read well grammatically is difficult to understand or nonintuitive at best and misleading or outrightly nonsensical at worst.
There's a huge difference in the expressiveness of this code
versus the lack of expressiveness in this code:
Also, as a matter of style, don't compare a boolean variable with true or false. That is redundant and error prone because it's very easy to type = false instead of == false.
Campbell Ritchie wrote:Find out about enumerated types for the symbols. I think you may need a Square class too. Your array would be Square[3][3] not [2][2]. 2 is the index, but the numbers you want are the sizes: 3.
Sean Paulson wrote:
Junilu Lacar wrote:You could also just use reference equality. Since you only have two players, then this code should work:
...
IMO, this is more straightforward and reads better.
Ok i see what you are saying i will probably go with this.
Sean Paulson wrote:
I have 5 classes actually seems like a lot but youll see why.
CLASSES:tickTackToe(main), game, player(player class is just a sub class to activePlayer class that does not have any methods), activePlayer, board.
Junilu Lacar wrote:Now to object-orientation.
... This is the principle of abstraction ... Showing intent/purpose while hiding implementation details is what abstraction is about in general
Junilu Lacar wrote:You could also just use reference equality.
Junilu Lacar wrote:
Your code references a player (should be Player) class but I don't see any code for that class. You must have it somewhere, otherwise your code will not compile. From what you said, it probably looks something like this:
Sean Paulson wrote:im not sure if i know what you mean by using reference equality.
Sean Paulson wrote:yeah i have more classes i can upload them if you would like a look at it.
Junilu Lacar wrote:Now to object-orientation...
Sean Paulson wrote:I also like how simply you are switching players by creating another currentPlayer obj? otherObject (basically a temporary holder).
Junilu Lacar wrote:Here's one more step to more self-documenting code:
This is a result of extracting line 14, which used to be on line 7, to its own method and leaving an intention-revealing name in its place. This is known as Extract Method refactoring. This makes the play() method a Composed Method that has a Single Level of Abstraction
Junilu Lacar wrote:In the Board class, you wrote:
Reading just this method, these things come to mind:
1. Why do we need to save the parameter values with lines 75 & 76? The motivation to do that seems questionable and makes this code smelly.
2. Lines 78 and 79 are not idiomatic. Should be < 3 instead of <= 2. I already commented on this previously.
3. Line 82 is kind of smelly, a return statement from deep inside a nested for-loop is not something you want to get into a habit of doing.
4. Lines 86 and 87 mix in the task of displaying a message with the other things that the method is doing that's not related to display. Try to keep display tasks separate from calculations.
5. The name setMove is not logically or grammatically compatible with a Boolean return value. "Set move" is an imperative sentence, it's a command to do something. A boolean return value implies a query that is answerable by "Yes" or "No", "True" or "False". Again, you are mixing concerns here and crossing signals. This makes the semantics of the setMove() method confusing.
6. Method names that start with "set" are usually taken to be following the Java bean convention for mutator method names, also known as setters. So, a method named setName() is expected to set the value of an object's name field to something. Your setMove() method does not behave like a conventional mutator/setter. That makes your code misleading.
7. Your use of the names playerSymbol and userSymbol seems arbitrary. Why the change from "user" to "player"? How does the "user" prefix add/contribute to the semantics of the code? There might be some significance in naming the parameter as just symbol and then assigning its value to a variable named playerSymbol but I don't see any value in essentially saying that "the userSymbol is the playerSymbol". This is assuming that you can even justify the need to save these values in the first place, as I noted in #1 above.
Sean Paulson wrote:i have not even heard of extract method refactoring or the such (i dont even think the books im using mention those
Sean Paulson wrote:
3.Should i use a break statement and just change the value of win?Junilu Lacar wrote:3. Line 82 is kind of smelly, a return statement from deep inside a nested for-loop is not something you want to get into a habit of doing.
You didn't tell me he was so big. Unlike this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|