說個老生常談的問題的了，就是簡單工廠模式到底是不是違背了開閉原則？

在討論之前，先重溫下什麼是開閉原則。

開閉原則(open/closed principle)的定義是,software entities (classes, modules, functions) should be open for extension, but closed for modification,一個類開放它的拓展，關閉它的修改，即一個類可以允許拓展它的功能，而不允許修改它的原始碼。

先舉個簡單的例子，關於開閉原則的，看下面一段程式碼

class DefenseBuff
{
        private int m_buffType;

        public int BuffType
        {
            get { return m_buffType; }
            set { m_buffType = value; }
        }

        public int GetDiscountDamage(int TotalDamage)
        {
                if (m_buffType == 1)
                {
                    return TotalDamage - 100;
                }
                else
                {
                    return TotalDamage - 50;
                }
        }
}
 

上面的問題在於，如果策劃要加一個buff種類，你必須又加一個if-else的條件判斷，這樣會造成無休止的修改此類,然後再次測試此類能否正常執行，包括引用到它的類又能否正常執行。如果到後期系統越變越龐大，則非常難維護。

這就是違背了開閉原則。

如果我們改成下面這樣：用繼承和多型的方式，如果加了新的型別，我們只要建立一個新的子類就行了，這樣就不會違背開閉原則

class DefenseBuff
{
        public virtual int GetDiscountDamage(int TotalDamage)
        {
            return TotalDamage;
        }
}

class SilverDefenseBuff : DefenseBuff
{
	public override int GetDiscountDamage(int TotalDamage)
	{
		return base.GetDiscountDamage(TotalDamage) - 50;
	}
}

class GoldDefenseBuff : DefenseBuff
{
	public override int GetDiscountDamage(int TotalDamage)
	{
		return base.GetDiscountDamage(TotalDamage) - 100;
	}
}
 

或者我們可以重Excel資料表中讀資料，然而在現實開發中，策劃一般把數值寫在Excel表中的，不會向上面那樣寫死的，然而我們也不需要再修改程式碼，而策劃可以任意修改數值和增加型別。

class DefenseBuff
{
	private int m_buffType;

	public int BuffType
	{
		get { return m_buffType; }
		set { m_buffType = value; }
	}
    public DefenseBuff(int buffType)
	{
		m_buffType = buffType;
	}
	public int GetDiscountDamage(int TotalDamage)
	{
		return BuffTable.GetType(m_buffType).DiscountDamage;//從excel配置表讀取資料
	}
}
var player = WorldMap.Instance.GetSelfPlayer();
Monster m = WorldMap.Instance.GetMonsterPool().GetAt(0);
DefenseBuff bf = new DefenseBuff(PlayerProperty.Instance.GetMetaData(player.ID).buffType);
player.Damage(bf.GetDiscountDamage(MonsterTable.GetType(m.ID)).AttackDamage));
 

說完了開閉原則，現在來說一下簡單工廠模式，看下面程式碼：

using System;

enum MonsterType
{
	SKELETON,
	GHOUST,
	EVIL,
	CACODEMON
}

abstract class Monster
{
	public abstract int AttackDamage { get; }
}
	
class Skeleton : Monster
{
	public override int AttackDamage
	{
		get
		{
			return 10;
		}
		
	}
}

class Ghoust : Monster
{
	public override int AttackDamage
	{
		get
		{
			return 20;
		}
	}
}

class Evil : Monster
{
	public override int AttackDamage
	{
		get
		{
			return 50;
		}
	}
}

class Cacodemon : Monster
{
	public override int AttackDamage
	{
		get
		{
			return 100;
		}
	}
}

static class MonsterFactory
{
	public static Monster Create(MonsterType monster_type)
	{
		switch(monster_type)
		{
			case MonsterType.SKELETON:
				return new Skeleton();
			case MonsterType.GHOUST:
				return new Ghoust();
			case MonsterType.EVIL:
				return new Evil();
			case MonsterType.CACODEMON:
				return new Cacodemon();
		}
	}
}


var player = WorldMap.Instance.GetSelfPlayer();
var monster = MonsterFactory.Create(MonsterType.SKELETON);
player.Damage(monster.AttackDamage);

上述程式碼的問題就在於，如果策劃要加一個新的怪物類，那我們就必須增加一個Swith-Case條件，就必須修改MonsterFactory的內部程式碼，這個其實在一定程度上也已經違背了開閉原則

如果改成下面的方式，類似於抽象工廠的方式，如果新加了一個怪物類，我們只要新增一個MonsterInfo的子類即可，就不會違背開閉原則了。

public abstract class MonsterInfo
{
    public abstract Monster CreateMonster();
}

public class SkeletonInfo : MonsterInfo
{
    public override Skeleton CreateMonster()
    {
        return new Skeleton();
    }
}

public class GhoustInfo : MonsterInfo
{
	public override Ghoust CreateMonster()
	{
		return new Ghoust();
	}
}

public static class MonsterFactory
{
    public static Monster Create(MonsterInfo aInfo)
    {       
        return aInfo.CreateMonster();
    }
}
var player = WorldMap.Instance.GetSelfPlayer();
var monster = MonsterFactory.Create(new SkeletonInfo());
player.Damage(monster.AttackDamage);

或者我們使用泛型，會更簡潔方便

static class MonsterFactory<T> where T : Monster,new()
{
	public static Monster Create()
	{
		return new T();
	}
}
var player = WorldMap.Instance.GetSelfPlayer();
var monster = MonsterFactory<Skeleton>.Create();
player.Damage(monster.AttackDamage);

或者使用反射的方式:

public static class MonsterFactory
{
	public static Monster Create(Type monsterType)
	{
		return Activator.CreateInstance(monsterType) as Monster;
	}
	
	public static Monster Create(string monsterType)
	{
		Type type = Assembly.GetExecutingAssembly().GetType(monsterType);
        return Activator.CreateInstance(type) as Monster;
	}
}
var player = WorldMap.Instance.GetSelfPlayer();
var monster1 = MonsterFactory.Create(typeof(SkeletonInfo));
var monster2 = MonsterFactory.Create("Ghoust");
player.Damage(monster1.AttackDamage);
player.Damage(monster2.AttackDamage);

綜上所述，我們基本可以認為帶過多的switch-case或if-else的簡單工廠模式是違背開閉原則的，會增加程式碼的耦合度，會造成當系統變得龐大時，極其難以維護。

其實我們有很多的方法，可以繞開過多swith-case或if-else的條件，以滿足開閉原則來實現簡單的工廠模式。

關於更多的工廠模式和開閉原則，我們今後再繼續討論,今天先說這麼多。如果有什麼錯誤或不對的，歡迎大家多多指正。