Lesson 12.6: Refactoring after adding Actions

We’ve made many changes recently. Let’s take a moment to do some refactoring.

 

 

 

Lesson Steps

Step 1: Create Engine\Actions\BaseAction.cs

All our action classes will share some similar functions. So, let’s put them in a base class.

 

We never need a BaseAction object. We’ll only instantiate children of BaseAction. So, we’re making this an “abstract” class, which cannot be instantiated on its own – only through its child classes.

 

Move the OnActionPerformed event and ReportResult function into BaseAction. Notice that the event is still public, because other objects will subscribe to this event (the LivingEntity class).

However, the ReportResult function and _itemInUse variable are protected. This is so BaseAction’s child classes can use them.

 

I’ve also created a protected BaseAction constructor that accepts a GameItem parameter “itemInUse” and saves it to the protected “_itemInUse” variable.

 

BaseAction.cs

 

 

Step 2: Modify Engine\Actions\AttackWithWeapon.cs and Heal.cs

Now we can remove the code in the new base class from its children.

 

Remove the OnActionPerformed event, the ReportResult function, the _weapon variable from AttackWithWeapon, and the

 

I’ve also renamed the “weapon” parameter and variable from AttackWithWeapon, and the “item” parameter and variable from Heal. We’ll use the _itemInUse variable from BaseAction.

 

We’re combining an abstract base class with an interface here.

If we implemented all the interface requirements in the base class, we could change BaseAction to “public abstract class BaseAction : IAction”, and remove the ” : IAction” from the child classes. The child classes would still be IAction objects, because their parent class is an IAction object.

But, in this situation, we cannot put the Execute function (which is required in the interface) in the base class. Each Action child class has unique code in their Execute function. So, we need to have ” : IAction” in each child class.

 

AttackWithWeapon.cs

 

Heal.cs

 

 

Step 3: Run the unit tests and play the game, to ensure the refactoring changes didn’t break anything.

 

Return to main page

Leave a Reply

Your email address will not be published. Required fields are marked *