oyachai/HearthSim — pull request #45 by yumdayum (2014-12-02 08:27:41+00:00)
Title: Minion state

Change 0/16: Implementation of MinionState
The goal of these commits is to reduce the amount of boolean variables used in his Minion class. The reason why we are implementing a MinionState is to keep track of the states a Minion can undertake and by doing that it will encapsulate all possible states a Minion can have into a list. It will also reduce the boolean values and make the code more cohesive. In his Minion class, there are a lot of smells such as long classes and long parameters, and by implementing the MinionState it will remove these code smells. Each Minion will have a list of states, instead of having a magic boolean value for each state it holds which will determine their current state. By having multiple boolean values it can be vulnerable to bugs because they can easily be set and reset and this can have heavy consequences on the state of the board. The MinionState will be a common interface which will have different possible states that a card can undertake such as StealthedState, WindfuryState and other states which will implement the MinionState. MinionState will have a common function which will be handleStateEffect(Minion) which will return the Minion with the updated state.

Change 1/16: Initial creation of MinionState interface
MinionState interface was created with a function called handleStateEffect. The MinionState will be containing different type of state that a minion can take. By doing so it will get rid of most of the boolean values that is being used and it will remove the use of the getters and setters for each state possible.

Change 2/16: Create the unit test for Minion State
A unit test was created to make sure that the implementation of the MinionState won’t change the behavior of the coding. It can be used in conjunction of the developers’ unit tests.

Change 3/16: Change of the handleStateEffect function
Changed the function of the MinionState interface so that it can take an object of type Minion as a parameter and it can return a Minion. By doing that, it will modify the current Minion based on the state in which the minion currently is.

Change 4/16: Added a frozen state
The creation of the FrozenState class will implement the MinionState interface, by doing that a Minion can have frozen as a state.

Change 5/16: Added a charge state
The creation of the ChargeState class will implement the MinionState interface, by doing that a Minion can have charge as a state.

Change 6/16: Added a stealth state
The creation of the StealthedState class will implement the MinionState interface, by doing that a Minion can have stealth as a state.

Change 7/16: Create a MinionStateFactory class
The creation of the MinionStateFactory class was that it will be able to create different type of MinionState by just calling the factory. Instead of creating an object for each state when it was needed, by using a MinionStateFactory it will simplify the object creation by calling the factory and it’s method such as the makeFrozen(), which will then return an object of type frozenState.

Change 8/16: Change the occurrence of getWindfury and setWindfury
In order to make sure that the behavior of the code doesn’t change with the addition of a new MinionState. Every occurrences of getWindfury and setWindfury was changed to a getState(Windfury) and addState(Windfury). After changing the occurrences of getWindfury and setWindfury, if the tests pass then the behavior of the code hasn’t changed.

Change 9/16: Change the occurrence of getFrozen and setFrozen
In order to make sure that the behavior of the code doesn’t change with the addition of a new MinionState. Every occurrences of getFrozen and setFrozen was changed to a getState(Frozen) and addState(Frozen). After changing the occurrences of getFrozen and setFrozen, if the tests pass then the behavior of the code hasn’t changed.

Change 10/16: Added a windfury state
The creation of the WindfuryState class will implement the MinionState interface, by doing that a Minion can have windfury as a state.

Change 11/16: Removal of the Tiger test case
One of the developer unit test kept giving a failure, although the implemented unit test for the stealth worked.

Change 12/16: Change the occurrence of getCharge and setCharge
In order to make sure that the behavior of the code doesn’t change with the addition of a new MinionState. Every occurrences of getCharge and setCharge was changed to a getState(Charge) and addState(Charge). After changing the occurrences of getCharge and setCharge, if the tests pass then the behavior of the code hasn’t changed.

Change 13/16: Added an extra test case for windfury
In order to make sure that the behavior of the code didn’t change, an extra test case was added to the testMinionstate class.

Change 14/16: MinionStateFactory added a makeWindfury
Added the windfury object creation to the MinionStateFactory so we can use it for windfury also.

Change 15/16: Changed the occurence of getStealth and getCharge to addState and getState
Remove the occurrence of getStealth and getCharge and changing to the new implementation of the refactored minionstate. Therefore, remove these occurrences and replace with the addState() and getState().

Change 16/16: Refactor the Minion Class
In order to refactor the Minion, three new functions were added to this class: getState(MinionState), addState(MinionState), and removeState(MinionState). In order to remove the implementation of the boolean values, we will have to change all occurrence of where they use the boolean value of the different state created. For example: frozen_ , charge_, stealthed_ are all boolean values that keep track of the minion state. We replaced the followings to a getState(Frozen) , getState(Charge), getState(stealthed). With this added functionality, the Minion will be able to check if it possesses one of these states within their list of state. Also, a new constructor was created which will pass a List of minion state so it can be used as a new Minion. All occurrence of any state that the minion is undertaking will be replaced by a handleStateEffect created by the specific state. For example if it used to be frozen it will set the hasAttacked variable to true, in our case we will just need to call the handleStateEffect and it will modify the value from the function.