簡單工廠、工廠方法、抽象工廠、策略模式、策略與工廠的區別

時間 2019-12-10

標籤簡單工廠方法抽象策略模式區別简体版

原文原文鏈接

結合簡單示例和UML圖，講解工廠模式簡單原理。java

1、引子算法

話說十年前，有一個爆發戶，他家有三輛汽車（Benz（奔馳）、Bmw（寶馬）、Audi（奧迪）），還僱了司機爲他開車。不過，爆發戶坐車時老是這樣：上Benz車後跟司機說「開奔馳車！」，坐上Bmw後他說「開寶馬車！」，坐上 Audi後他說「開奧迪車！」。
你必定說：這人有病！直接說開車不就好了？！而當把這個爆發戶的行爲放到咱們程序語言中來，咱們發現C語言一直是經過這種方式來坐車的！
幸運的是這種有病的現象在OO語言中能夠避免了。下面以Java語言爲基礎來引入咱們本文的主題：工廠模式！數組

2、簡介this

工廠模式主要是爲建立對象提供了接口。工廠模式按照《Java與模式》中的提法分爲三類：
1. 簡單工廠模式(Simple Factory)
2. 工廠方法模式(Factory Method)
3. 抽象工廠模式(Abstract Factory)
這三種模式從上到下逐步抽象，而且更具通常性。還有一種分類法，就是將簡單工廠模式看爲工廠方法模式的一種特例，兩個歸爲一類。二者皆可，這本爲使用《Java與模式》的分類方法。
在什麼樣的狀況下咱們應該記得使用工廠模式呢？大致有兩點：
1.在編碼時不能預見須要建立哪一種類的實例。
2.系統不該依賴於產品類實例如何被建立、組合和表達的細節
工廠模式能給咱們的OOD、OOP帶來哪些好處呢？？編碼

3、簡單工廠模式spa

這個模式自己很簡單並且使用在業務較簡單的狀況下。通常用於小項目或者具體產品不多擴展的狀況（這樣工廠類纔不用常常更改）。
它由三種角色組成：
工廠類角色：這是本模式的核心，含有必定的商業邏輯和判斷邏輯，根據邏輯不一樣，產生具體的工廠產品。如例子中的Driver類。
抽象產品角色：它通常是具體產品繼承的父類或者實現的接口。由接口或者抽象類來實現。如例中的Car接口。
具體產品角色：工廠類所建立的對象就是此角色的實例。在java中由一個具體類實現，如例子中的Benz、Bmw類。.net

來用類圖來清晰的表示下的它們之間的關係：設計

下面就來給那個暴發戶治病：在使用了簡單工廠模式後，如今暴發戶只須要坐在車裏對司機說句：「開車」就能夠了。來看看怎麼用代碼實現的：（爲方便起見，全部的類放在一個文件中，故有一個類被聲明爲public）3d

Java代碼對象

//抽象產品
abstract class Car{
private String name;
public abstract void drive();
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
//具體產品
class Benz extends Car{
public void drive(){
System.out.println(this.getName()+"----go-----------------------");
}
}
class Bmw extends Car{
public void drive(){
System.out.println(this.getName()+"----go-----------------------");
}
}
//簡單工廠
class Driver{
public static Car createCar(String car){
Car c = null;
if("Benz".equalsIgnoreCase(car))
c = new Benz();
else if("Bmw".equalsIgnoreCase(car))
c = new Bmw();
return c;
}
}
//老闆
public class BossSimplyFactory {
public static void main(String[] args) throws IOException {
//老闆告訴司機我今天坐奔馳
Car car = Driver.createCar("benz");
car.setName("benz");
//司機開着奔馳出發
car.drive();
}
<span style="font-family: courier new,courier;">}</span>

若是老闆要坐奧迪，同理。

這即是簡單工廠模式了。那麼它帶了了什麼好處呢？
首先，符合現實中的狀況；並且客戶端免除了直接建立產品對象的責任，而僅僅負責「消費」產品（正如暴發戶所爲）。
下面咱們從開閉原則上來分析下簡單工廠模式。當暴發戶增長了一輛車的時候，只要符合抽象產品制定的合同，那麼只要通知工廠類知道就能夠被客戶使用了。（即建立一個新的車類，繼承抽象產品Car）那麼對於產品部分來講，它是符合開閉原則的——對擴展開放、對修改關閉；可是工廠類不太理想，由於每增長一輛車，都要在工廠類中增長相應的商業邏輯和判斷邏輯，這顯天然是違背開閉原則的。

而在實際應用中，極可能產品是一個多層次的樹狀結構。因爲簡單工廠模式中只有一個工廠類來對應這些產品，因此這可能會把咱們的上帝類壞了。
正如我前面提到的簡單工廠模式適用於業務簡單的狀況下或者具體產品不多增長的狀況。而對於複雜的業務環境可能不太適應了。這就應該由工廠方法模式來出場了！！

4、工廠方法模式
抽象工廠角色：這是工廠方法模式的核心，它與應用程序無關。是具體工廠角色必須實現的接口或者必須繼承的父類。在java中它由抽象類或者接口來實現。
具體工廠角色：它含有和具體業務邏輯有關的代碼。由應用程序調用以建立對應的具體產品的對象。在java中它由具體的類來實現。
抽象產品角色：它是具體產品繼承的父類或者是實現的接口。在java中通常有抽象類或者接口來實現。
具體產品角色：具體工廠角色所建立的對象就是此角色的實例。在java中由具體的類來實現。
來用類圖來清晰的表示下的它們之間的關係：

話說暴發戶生意越作越大，本身的愛車也愈來愈多。這可苦了那位司機師傅了，什麼車它都要記得，維護，都要通過他來使用！因而暴發戶同情他說：我給你分配幾我的手，你只管管好他們就好了！因而工廠方法模式的管理出現了。代碼以下：

Java代碼

//抽象產品
abstract class Car{
private String name;
public abstract void drive();
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
//具體產品
class Benz extends Car{
public void drive(){
System.out.println(this.getName()+"----go-----------------------");
}
}
class Bmw extends Car{
public void drive(){
System.out.println(this.getName()+"----go-----------------------");
}
}
//抽象工廠
abstract class Driver{
public abstract Car createCar(String car) throws Exception;
}
//具體工廠（每一個具體工廠負責一個具體產品）
class BenzDriver extends Driver{
public Car createCar(String car) throws Exception {
return new Benz();
}
}
class BmwDriver extends Driver{
public Car createCar(String car) throws Exception {
return new Bmw();
}
}
//老闆
public class Boss{
public static void main(String[] args) throws Exception {
Driver d = new BenzDriver();
Car c = d.createCar("benz");
c.setName("benz");
c.drive();
}
}

使用開閉原則來分析下工廠方法模式。當有新的產品（即暴發戶的汽車）產生時，只要按照抽象產品角色、抽象工廠角色提供的合同來生成，那麼就能夠被客戶使用，而沒必要去修改任何已有的代碼。（即當有新產品時，只要建立並基礎抽象產品；新建具體工廠繼承抽象工廠；而不用修改任何一個類）工廠方法模式是徹底符合開閉原則的！

使用工廠方法模式足以應付咱們可能遇到的大部分業務需求。可是當產品種類很是多時，就會出現大量的與之對應的工廠類，這不該該是咱們所但願的。因此我建議在這種狀況下使用簡單工廠模式與工廠方法模式相結合的方式來減小工廠類：即對於產品樹上相似的種類（通常是樹的葉子中互爲兄弟的）使用簡單工廠模式來實現。
固然特殊的狀況，就要特殊對待了：對於系統中存在不一樣的產品樹，並且產品樹上存在產品族（下一節將解釋這個名詞）。那麼這種狀況下就可能可使用抽象工廠模式了。

5、小結

讓咱們來看看簡單工廠模式、工廠方法模式給咱們的啓迪：
若是不使用工廠模式來實現咱們的例子，也許代碼會減小不少——只須要實現已有的車，不使用多態。可是在可維護性上，可擴展性上是很是差的（你能夠想象一下添加一輛車後要牽動的類）。所以爲了提升擴展性和維護性，多寫些代碼是值得的。

6、抽象工廠模式

先來認識下什麼是產品族：位於不一樣產品等級結構中，功能相關聯的產品組成的家族。

圖中的BmwCar和BenzCar就是兩個產品樹（產品層次結構）；而如圖所示的BenzSportsCar和BmwSportsCar就是一個產品族。他們均可以放到跑車家族中，所以功能有所關聯。同理BmwBussinessCar和BenzBusinessCar也是一個產品族。
能夠這麼說，它和工廠方法模式的區別就在於須要建立對象的複雜程度上。並且抽象工廠模式是三個裏面最爲抽象、最具通常性的。抽象工廠模式的用意爲：給客戶端提供一個接口，能夠建立多個產品族中的產品對象。
並且使用抽象工廠模式還要知足一下條件：
1.系統中有多個產品族，而系統一次只可能消費其中一族產品
2.同屬於同一個產品族的產品以其使用。
來看看抽象工廠模式的各個角色（和工廠方法的一模一樣）：
抽象工廠角色：這是工廠方法模式的核心，它與應用程序無關。是具體工廠角色必須實現的接口或者必須繼承的父類。在java中它由抽象類或者接口來實現。
具體工廠角色：它含有和具體業務邏輯有關的代碼。由應用程序調用以建立對應的具體產品的對象。在java中它由具體的類來實現。
抽象產品角色：它是具體產品繼承的父類或者是實現的接口。在java中通常有抽象類或者接口來實現。
具體產品角色：具體工廠角色所建立的對象就是此角色的實例。在java中由具體的類來實現。

Java代碼

//抽象產品（Bmw和Audi同理）
abstract class BenzCar{
private String name;
public abstract void drive();
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
//具體產品（Bmw和Audi同理）
class BenzSportCar extends BenzCar{
public void drive(){
System.out.println(this.getName()+"----BenzSportCar-----------------------");
}
}
class BenzBusinessCar extends BenzCar{
public void drive(){
System.out.println(this.getName()+"----BenzBusinessCar-----------------------");
}
}
abstract class BmwCar{
private String name;
public abstract void drive();
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
class BmwSportCar extends BmwCar{
public void drive(){
System.out.println(this.getName()+"----BmwSportCar-----------------------");
}
}
class BmwBusinessCar extends BmwCar{
public void drive(){
System.out.println(this.getName()+"----BmwBusinessCar-----------------------");
}
}
abstract class AudiCar{
private String name;
public abstract void drive();
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
class AudiSportCar extends AudiCar{
public void drive(){
System.out.println(this.getName()+"----AudiSportCar-----------------------");
}
}
class AudiBusinessCar extends AudiCar{
public void drive(){
System.out.println(this.getName()+"----AudiBusinessCar-----------------------");
}
}
//抽象工廠
abstract class Driver3{
public abstract BenzCar createBenzCar(String car) throws Exception;
public abstract BmwCar createBmwCar(String car) throws Exception;
public abstract AudiCar createAudiCar(String car) throws Exception;
}
//具體工廠
class SportDriver extends Driver3{
public BenzCar createBenzCar(String car) throws Exception {
return new BenzSportCar();
}
public BmwCar createBmwCar(String car) throws Exception {
return new BmwSportCar();
}
public AudiCar createAudiCar(String car) throws Exception {
return new AudiSportCar();
}
}
class BusinessDriver extends Driver3{
public BenzCar createBenzCar(String car) throws Exception {
return new BenzBusinessCar();
}
public BmwCar createBmwCar(String car) throws Exception {
return new BmwBusinessCar();
}
public AudiCar createAudiCar(String car) throws Exception {
return new AudiBusinessCar();
}
}
//老闆
public class BossAbstractFactory {
public static void main(String[] args) throws Exception {
Driver3 d = new BusinessDriver();
AudiCar car = d.createAudiCar("");
car.drive();
}
}

其中：BenzSportCar和BenzBusinessCar屬於產品樹；同理BmwSportCar和BmwBusinessCar。而BenzSportCar和BmwSportCar和AudiSportCar屬於產品族。

因此抽象工廠模式通常用於具備產品樹和產品族的場景下。

抽象工廠模式的缺點：若是須要增長新的產品樹，那麼就要新增三個產品類，好比VolvoCar，VolvoSportCar,VolvoSportCar，而且要修改三個工廠類。這樣大批量的改動是很醜陋的作法。

因此能夠用簡單工廠配合反射來改進抽象工廠：
UML圖略。

Java代碼

abstract class BenzCar{
private String name;
public abstract void drive();
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
class BenzSportCar extends BenzCar{
public void drive(){
System.out.println(this.getName()+"----BenzSportCar-----------------------");
}
}
class BenzBusinessCar extends BenzCar{
public void drive(){
System.out.println(this.getName()+"----BenzBusinessCar-----------------------");
}
}
abstract class BmwCar{
private String name;
public abstract void drive();
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
class BmwSportCar extends BmwCar{
public void drive(){
System.out.println(this.getName()+"----BmwSportCar-----------------------");
}
}
class BmwBusinessCar extends BmwCar{
public void drive(){
System.out.println(this.getName()+"----BmwBusinessCar-----------------------");
}
}
abstract class AudiCar{
private String name;
public abstract void drive();
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
class AudiSportCar extends AudiCar{
public void drive(){
System.out.println(this.getName()+"----AudiSportCar-----------------------");
}
}
class AudiBusinessCar extends AudiCar{
public void drive(){
System.out.println(this.getName()+"----AudiBusinessCar-----------------------");
}
}
/**
* 簡單工廠經過反射改進抽象工廠及其子工廠
* @author Administrator
*
*/
class Driver3{
public static BenzCar createBenzCar(String car) throws Exception {
return (BenzCar) Class.forName(car).newInstance();
}
public static BmwCar createBmwCar(String car) throws Exception {
return (BmwCar) Class.forName(car).newInstance();
}
public static AudiCar createAudiCar(String car) throws Exception {
return (AudiCar) Class.forName(car).newInstance();
}
}
//客戶端
public class SimpleAndAbstractFactory {
public static void main(String[] args) throws Exception {
AudiCar car = Driver3.createAudiCar("com.java.pattendesign.factory.AudiSportCar");
car.drive();
}
}

策略模式

從策略一詞來看,策略模式是種傾向於行爲的模式.有點相似找仗時的作戰方案，通常司令員在作戰前都會根據實際狀況作出幾套不一樣的方案，若是當時狀況有變，就會根據相應的條件來斷定用哪一套方案來替換原定方案。但不管如何替換，替換多少次，仗仍是要打的。

舉例：導出成EXCEL，WORD，PDF文件的功能，這三類導出雖然具體操做略有不一樣，可是大部分都相同。

策略模式與工廠模式從uml圖上來講，基本一致。只是強調的封裝不一樣。咱們以工廠模式和策略模式的比較來說解策略模式。

工廠模式咱們能夠作以下理解：假設有Audi的公司生產汽車，它掌握一項核心的技術就是生產汽車，另外一方面，它生產的汽車是有不一樣型號的，而且在不一樣的生產線上進行組裝。當客戶經過銷售部門進行預約後，Audi公司將在指定的生產線上爲客戶生產出它所須要的汽車。

策略(Strategy)模式在結構上與工廠模式相似，惟一的區別是工廠模式實例化一個產品的操做是在服務端來作的，換句話說客戶端傳達給服務端的只是某種標識，服務端根據該標識實例化一個對象。而策略模式的客戶端傳達給服務端的是一個實例，服務端只是將該實例拿過去在服務端的環境裏執行該實例的方法。這就比如一個對汽車不甚瞭解的人去買車，他在那一比劃，說要什麼什麼樣的，銷售部門根據他的這個「比劃」來造成一份訂單，這就是工廠模式下的工做方式。而策略模式下那個顧客就是個行家，他本身給出了訂單的詳細信息，銷售部門只是轉了一下手就交給生產部門去作了。經過兩相對比，咱們不難發現，採用工廠模式必須提供足夠靈活的銷售部門，若是用戶有了新的需求，銷售部門必須立刻意識到這樣才能夠作出合適的訂單。因此倘一款新車出來了，生產部門和銷售部門都須要更新，對顧客來講也須要更新對新車的描述因此須要改動的地方有三處。而策略模式中的銷售部門工做比較固定，它只負責接受訂單並執行特定的幾個操做。當一款新車出來時，只須要對服務端的生產部門和客戶端的代碼進行更新，而不須要更新銷售部門的代碼。

技術支持：簡單工廠和策略的基礎都是由於面向對象的封裝與多態。他們實現的思想都是先設定一個抽象的模型並從該模型派生出符合不一樣客戶需求的各類方法，並加以封裝。

工廠模式和策略模式的區別在於實例化一個對象的位置不一樣，對工廠模式而言，實例化對象是放在服務端的，即放在了工廠類裏面；

而策略模式實例化對象的操做在客戶端，服務端的「銷售部門」只負責傳遞該對象，並在服務端的環境裏執行特定的操做。。。

工廠模式要求服務端的銷售部門足夠靈敏，而策略模式因爲對策略進行了封裝，因此他的銷售部門比較傻，須要客戶提供足夠能區分使用哪一種策略的參數，而這最好的就是該策略的實例了。

Java代碼

//抽象產品
abstract class AudiCar{
private String name;
public abstract void makeCar();
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
//具體產品
class AudiA6 extends AudiCar{
public void makeCar(){
System.out.println(this.getName()+"----go-----------------------");
}
}
class AudiA4 extends AudiCar{
public void makeCar(){
System.out.println(this.getName()+"----go-----------------------");
}
}
//銷售部門----服務端
class CarContext {
AudiCar audiCar = null;
public CarContext(AudiCar audiCar) {
this.audiCar = audiCar;
}
public void orderCar(){
this.audiCar.makeCar();
}
}
//客戶----客戶端（這個客戶是內行，什麼都懂，他說我要A6，銷售部門馬上給他a6，因此銷售部門不用很懂）
public class SimplyFactoryAndStrategy2 {
public static void main(String[] args) throws IOException {
//客戶說我要什麼什麼樣子的車子，銷售人員才知道他要什麼樣子的車子
AudiCar car = new AudiA6();
car.setName("a6");
CarContext context = new CarContext(car);
context.orderCar();
}
}
//工廠模式---與上面的策略模式比較
//抽象產品
abstract class AudiCar{
private String name;
public abstract void makeCar();
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
//具體產品
class AudiA6 extends AudiCar{
public void makeCar(){
System.out.println(this.getName()+"----go-----------------------");
}
}
class AudiA4 extends AudiCar{
public void makeCar(){
System.out.println(this.getName()+"----go-----------------------");
}
}
//簡單工廠---銷售部門----服務端
class CarFactroy{
public static AudiCar createCar(String car){
AudiCar c = null;
if("A6".equalsIgnoreCase(car))
c = new AudiA6();
else if("A4".equalsIgnoreCase(car))
c = new AudiA4();
return c;
}
}
//客戶----客戶端（這個客戶是外行，什麼都不懂，只要隨便描述下車，銷售部門才能知道他要那款車，因此銷售部門比較牛）
public class SimplyFactoryAndStrategy {
public static void main(String[] args) throws IOException {
System.out.print("請輸入您要坐的車：（A六、A4）");
String carName = new BufferedReader(new InputStreamReader(System.in)).readLine();
//客戶說我要什麼什麼樣子的車子，銷售人員才知道他要什麼樣子的車子
AudiCar car = CarFactroy.createCar(carName);
car.setName(carName);
car.makeCar();
}
}

策略模式的優缺點

策略模式的主要優勢有：

策略類之間能夠自由切換，因爲策略類實現自同一個抽象，因此他們之間能夠自由切換。
易於擴展，增長一個新的策略對策略模式來講很是容易，基本上能夠在不改變原有代碼的基礎上進行擴展。
避免使用多重條件，若是不使用策略模式，對於全部的算法，必須使用條件語句進行鏈接，經過條件判斷來決定使用哪種算法，在上一篇文章中咱們已經提到，使用多重條件判斷是很是不容易維護的。

策略模式的缺點主要有兩個：

維護各個策略類會給開發帶來額外開銷，可能你們在這方面都有經驗：通常來講，策略類的數量超過5個，就比較使人頭疼了。
必須對客戶端（調用者）暴露全部的策略類，由於使用哪一種策略是由客戶端來決定的，所以，客戶端應該知道有什麼策略，而且瞭解各類策略之間的區別，不然，後果很嚴重。例如，有一個排序算法的策略模式，提供了快速排序、冒泡排序、選擇排序這三種算法，客戶端在使用這些算法以前，是否是先要明白這三種算法的適用狀況？再好比，客戶端要使用一個容器，有鏈表實現的，也有數組實現的，客戶端是否是也要明白鏈表和數組有什麼區別？就這一點來講是有悖於迪米特法則的。

適用場景

作面向對象設計的，對策略模式必定很熟悉，由於它實質上就是面向對象中的繼承和多態，在看完策略模式的通用代碼後，我想，即便以前歷來沒有據說過策略模式，在開發過程當中也必定使用過它吧？至少在在如下兩種狀況下，你們能夠考慮使用策略模式，