Apart from what you have already been told for about two weeks on this thread?
The game consists of 100 rounds of above two players competing.
For instance, you should document that the Outcome.getWinner() method throws an IllegalStateException if isTie() returns true.
After you've written documentation, you can write unit tests for the expected behavior of your classes and methods. You may have to add additional methods and constructors to your classes to be able to finish the unit tests. You should also document these additional methods and constructors.
Isaac Ferguson wrote:Why? When isTie() returns true, it should thrown anything, isnt it?
For the exceptions, I dont find a clear way to know which one, should it thrown.
Exception | When? |
---|---|
IllegalArgumentException | The client passed invalid arguments to a method. |
IndexOutOfBoundsException | Same as IllegalArgumentException, except for arguments that are used as indices. |
IllegalStateException | The client tried to call a method that may not be called for the current object state. |
UnsupportedOperationException | The method is not supported yet, or never will be. |
AssertionError | Something happened that really should never happen. |
Any comments till this point?
Your @param descriptions for the Game constructor don't make sense: there are no types playerA and playerB.
Why are you initializing the outcomes list from a constructor parameter?
Is that supposed to be part of a documentation comment? If so, it is incorrect. You should have a separate @param tag for each parameter, and it should be followed by the parameter name and a brief description. More details here. You would want something like this:-And iff is a real word in computer sciences.Isaac Ferguson wrote:. . .
So like this should be correct ?
. . .
Isaac Ferguson wrote:So like this should be correct ?
When I dont do it, I get compilation errors like:
Don't get me started about those stupid light bulbs. |