初識設計模式1：簡單工廠模式

簡單工廠模式

簡單工廠模式是類的創建模式，又叫做靜態工廠方法模式。簡單工廠模式由一個工廠對象決定生產出哪一種產品類的實例。

為什麼要使用簡單工廠模式

原因很簡單：解耦。

LOL場景分析：

LOL中目前有100多個英雄，各個人物的技能全都不同，具體英雄的代碼實現必定不同；

但是每個英雄的技能都是Q、W、E、R這4個基本技能，以及召喚師技能D、F；

雖然選擇的英雄不同，但游戲的其他部分應該是完全相同的，不可能根據我們選擇的英雄不同，而完全改變其他通用部分的邏輯！

如何實現這樣的應用場景

召喚師技能常量類

public class SummonerSkillName {
  
  public static final String FLASH = "Flash";//閃現
  public static final String HEAL = "Heal";//治療
  public static final String IGNITE = "Ignite";//引燃
  public static final String REVIVE = "Revive";//懲戒
  public static final String TELEPORT = "Teleport";//傳送
  public static final String EXHAUST = "ExhaustSS";//虛弱
  
}

召喚師技能介面

public interface SummonerSkill {
  
  void release();//釋放技能
  
}

召喚師技能實現類1：閃現

public class FlashSS implements SummonerSkill {
  
  public static final String NAME = "閃現";
  
  @Override
  public void release() {
    System.out.println("閃現");
  }
  
}

召喚師技能實現類2：引燃

public class IgniteSS implements SummonerSkill {

  public static final String NAME = "引燃";

  @Override
  public void releaseSS() {
    System.out.println("引燃");
  }

}

召喚師技能工廠

public class SummonerSkillFactory {
  
  public static SummonerSkill getSkillSS(String ssName) throws Exception {
    
    SummonerSkill ss;
    if (ssName.equals(SummonerSkillName.FLASH)) {
      ss = new FlashSS();
    } else if (ssName.equals(SummonerSkillName.TELEPORT)) {
      ss = new TeleportSS();
    } else if (ssName.equals(SummonerSkillName.HEAL)) {
      ss = new HealSS();
    } else if (ssName.equals(SummonerSkillName.IGNITE)) {
      ss = new IgniteSS();
    } else if (ssName.equals(SummonerSkillName.EXHAUST)) {
      ss = new ExhaustSS();
    } else {
      ss = new ReviveSS();
    }
    
    return ss;
  }
  
}

改進之後的工廠，使用反射：

public class SummonerSkillFactory {
  
  private static final String CLASS_NAME_SUFFIX = "SS";
  
  public static SummonerSkill getSkillSS(String ssName) throws Exception {

    String className = ssName + classNameSuffix;
    String packageName = SummonerSkill.class.getPackage().getName();
    SummonerSkill ss = (SummonerSkill) Class.forName(packageName + "." + className).newInstance();
    
    return ss;
  }
  
}

腦補一下如果100多個英雄也用 if else，畫面得有多美~

這樣的好處不僅在於代碼編寫量小很多，而且假定新增召喚師技能的話，工廠的代碼不需要更改，遵守了開閉原則。

public class LeagueClient {
  
  @Test
  public void selectHero() throws Exception {
    SummonerSkill flash = SummonerSkillFactory.getSkillSS(SummonerSkillName.FLASH);
    SummonerSkill ignite = SummonerSkillFactory.getSkillSS(SummonerSkillName.IGNITE); 
}

簡單工廠模式或者說工廠模式的關註點並不在於在工廠中是如何生產出來需要的類的，而在於將創建產品與消費產品分離。

前面使用過if...else if...else、反射，除了這些方法，還可以有別的方法可以創建產品，比如傳入一個具體產品的標識，根據這個標識去資料庫裡面查詢。

工廠模式的優缺點

優點：

1、簡單優化了軟體體繫結構，明確了各自功能模塊的職責和權利

2、通過工廠類，外界不需要直接創建具體產品對象，只需要負責消費，不需要關心內部如何創建對象

缺點：

1、改進前的簡單工廠模式全部創建邏輯都集中在一個工廠類中，能創建的類只能是考慮到的，如果需要添加新的類，就必須改變工廠類了

2、改進前的簡單工廠模式隨著具體產品的不斷增多，可能會出現共產類根據不同條件創建不同實例的需求，這種對條件的判斷和對具體產品類型的判斷交錯在一起，很難避免功能模塊的蔓延，對系統的維護和擴展不利

3、改進後的簡單工廠模式主要是使用反射效率會低一些