Factory Design Pattern is used to centralizes all new object instantiation under 1 class, or in other words, having 1 class responsible for creating objects! The object created by Factory will use a common interface to be compatible with other related finer detail classes.

The objective of migrating creation responsibility is to prevent client class being exposed to many classes. Client class are the ones who uses these objects by instantiating them within itself. This posses a major risk where when a used class is removed or updated to a new name, the client class will crash unless updated to be in sync with them.

Imagine if there were 20 client classes using a class which frequently updates itself, you will need to re-update all 20 classes! The solution is to have an intermediary, such as a Factory Pattern to build those objects for the client. Those created objects will have a common interface (example: Weapon) for finer details (example: Sword, Bow, Axe, Polearm, Spear, Gun, Claw, Wand, Staff).

Before Implementing Factory Pattern

The code below shows a Client who couples to 4 weapon classes (sword, spear, bow and crossbow). Couples or coupling means having a relationship with another foreign class via instantiation or reference. If more classes were coupled between clients, it will multiply the coupling substantially.

public class ClientA
{
   public function ClientA
   {
      var sword:Sword = new Sword();
      var spear:Spear = new Spear();
      var bow:Bow = new Bow();
      var crossbow:Crossbow = new Crossbow();
   }
}
public class ClientB
{
   public function ClientB
   {
      var sword:Sword = new Sword();
      var spear:Spear = new Spear();
      var bow:Bow = new Bow();
      var crossbow:Crossbow = new Crossbow();
   }
}

As the example displayed above, 1 client has reference to 4 classes. 2 client makes it 8 (2 x 4 = 8). Now when the referenced classes increased to 6, you will have a total of 12 couplings (2 x 6 = 12). So how does this affects in software or game development? If 2 referenced class were to be updated/removed, those 2 clients have to be re-updated.

After Implementing Factory Pattern

Here is the code with Factory Pattern implemented. Noticed that both client A and B has instantiated a WeaponFactory to produce the weapons they need. They do not need to know the finer details of the weapon, but they get the weapon to be used. Similarly if you were purchasing a car, you drive it but not into manufacturing the car engine parts. As a user, you interact with the Car interface.

public class WeaponFactory
{
   public function WeaponFactory(){};
   public function create(type:String):Weapon
   {
      var weapon:Weapon;
      switch(type)
      {
          default:
          case 'Sword' : weapon = new Sword(); break;
          case 'Spear' : weapon = new Spear(); break;
          case 'Bow' : weapon = new Bow(); break;
          case 'Crossbow' : weapon = new Crossbow(); break;
      }
   }
}
public class ClientA
{
   public function ClientA
   {
      var weaponFactory:WeaponFactory = new WeaponFactory();
      var sword:Weapon = weaponFactory.create('Sword');
      var spear:Weapon = weaponFactory.create('Spear');
      var bow:Weapon = weaponFactory.create('Bow');
      var crossbow:Weapon = weaponFactory.create('Crossbow');
   }
}
public class ClientB
{
   public function ClientB
   {
      var weaponFactory:WeaponFactory = new WeaponFactory();
      var sword:Weapon = weaponFactory.create('Sword');
      var spear:Weapon = weaponFactory.create('Spear');
      var bow:Weapon = weaponFactory.create('Bow');
      var crossbow:Weapon = weaponFactory.create('Crossbow');
   }
}

In the program above, each client is interacting with Weapon Interface, not the Sword, Bow, Crossbow and Spear directly. These creates a loose coupling between client and weapon class. Any changes made in Sword affects 1 class, which is the Factory class. Since all instantiation or changes are done in 1 class, its easier to do maintenance without crashing other client classes.

Strategy Design Pattern is used to manage multiple subclasses (each implements various behaviors and shares some common behaviors) via composition instead of inheritance. This design pattern encapsulates each algorithm to be used interchangeably during runtime depending on client usage.

Basic Coding

This is what I used to code in my previous works. It’s simple and gets the thing done. When there are more weapons added, this class will be modified again. This poses risks where changing a class after testing might break it. Also, if there is complex formula involved in calculating the output for each weapon, this Weapon Class will be very difficult to read with hundreds or thousands lines of codes.

public class Weapon extends Object
{
   public var attack:int;
   public var soundEffect:String;
   public function getDamage(weaponType:String):int
   {
      if (weaponType == 'Sword' || weaponType == 'Spear')
      {
         return attack * 10;
      }
      if (weaponType == 'Bow' || weaponType == 'Crossbow')
      {
         return attack * 8;
      }
      return 0;
   }
   public function getSound(weaponType:String):int
   {
      if (weaponType == 'Sword' || weaponType == 'Bow')
      {
         return 'Boing';
      }
      if (weaponType == 'Spear' || weaponType == 'Crossbow')
      {
         return 'Boom';
      }
      return '';
   }
}

Advance Coding

Here I breakdown the main code into Interfaces and Multiple Classes. It seems that it requires more effort and more lines of codes compared to the basic coding. However, in the long term, it is easier to maintain the code as each class only holds a small portion of code (easier to read and find). Advance coding applies polymorphism (object with same method but does different things) and adheres to the principal of “Open for Extension, Close for Modification”.

public interface DamageFormula
{
   function getDamage():int;
}
public class MeleeDamageFormula implements DamageFormula
{
   public function getDamage(attack:int):int { return attack * 10; }
}
public class RangeDamageFormula implements DamageFormula
{
   public function getDamage(attack:int):int { return attack * 5; }
}
public interface SoundEffect
{
   function getSound():String;
}
public class BoingSoundEffect implements SoundEffect
{
   public function getSound():String { return 'Boing'; }
}
public class BoomSoundEffect implements SoundEffect
{
   public function getSound():String { return 'Boom'; }
}
public interface Weapon
{
   function getDamage():int;
   function getSound():String;
}
public class Sword implements Weapon
{
   public var attack:int;
   public var damageFormula:DamageFormula = new MeleeDamageFormula();
   public var soundEffect:SoundEffect = new BoingSoundEffect();
   public function getDamage():int { damageFormula.getDamage(attack); }
   public function getSound():String { soundEffect.getSound(); }
}
public class Spear implements Weapon
{
   public var attack:int;
   public var damageFormula:DamageFormula = new MeleeDamageFormula();
   public var soundEffect:SoundEffect = new BoomSoundEffect();
   public function getDamage():int { damageFormula.getDamage(attack); }
   public function getSound():String { soundEffect.getSound(); }
}
public class Bow implements Weapon
{
   public var attack:int;
   public var damageFormula:DamageFormula = new RangeDamageFormula();
   public var soundEffect:SoundEffect = new BoingSoundEffect();
   public function getDamage():int { damageFormula.getDamage(attack); }
   public function getSound():String { soundEffect.getSound(); }
}
public class Crossbow implements Weapon
{
   public var attack:int;
   public var damageFormula:DamageFormula = new RangeDamageFormula();
   public var soundEffect:SoundEffect = new BoomSoundEffect();
   public function getDamage():int { damageFormula.getDamage(attack); }
   public function getSound():String { soundEffect.getSound(); }
}

Summary

If I had to add more weapons and sound effects, basic coding becomes really messy and difficult to read with all of the if-statements conditions whereas for Advance Coding, it requires some time to properly manage these classes into folders.

The codes in Advance Coding section can be further simplified by implementing Factory Pattern which will be discussed in my subsequent post!