設計模式之簡單工廠模式

簡單工廠模式解釋：
簡單工廠模式（Simple Factory Pattern）屬於類的創新型模式，又叫靜態工廠方法模式（Static FactoryMethod Pattern）,是通過專門定義一個類來負責創建其他類的實例，被創建的實例通常都具有共同的父類。
工廠方法模式同樣屬於類的創建型模式又被稱爲多態工廠模式 。工廠方法模式的意義是定義一個創建產品對象的工廠接口，將實際創建工作推遲到子類當中。

簡單工廠模式的UML圖：

工廠角色： 這是簡單工廠模式的核心，由它負責創建所有的類的內部邏輯。當然工廠類必須能夠被外界調用，創建所需要的產品對象。
核心工廠類不再負責產品的創建，這樣核心類成爲一個抽象工廠角色，僅負責具體工廠子類必須實現的接口，這樣進一步抽象化的好處是使得工廠方法模式可以使系統在不修改具體工廠角色的情況下引進新的產品。

抽象產品角色：
簡單工廠模式所創建的所有對象的父類，注意，這裏的父類可以是接口也可以是抽象類，它負責描述所有實例所共有的公共接口。

具體產品角色：
簡單工廠所創建的具體實例對象，這些具體的產品往往都擁有共同的父類。

簡單工廠模式的深入分析
簡單工廠模式解決的問題是如何去實例化一個合適的對象。

簡單工廠模式的核心思想就是：有一個專門的類來負責創建實例的過程。
具體來說，把產品看着是一系列的類的集合，這些類是由某個抽象類或者接口派生出來的一個對象樹。而工廠類用來產生一個合適的對象來滿足客戶的要求。
如果簡單工廠模式所涉及到的具體產品之間沒有共同的邏輯，那麼我們就可以使用接口來扮演抽象產品的角色；如果具體產品之間有功能的邏輯或，我們就必須把這些共同的東西提取出來，放在一個抽象類中，然後讓具體產品繼承抽象類。爲實現更好複用的目的，共同的東西總是應該抽象出來的。
在實際的的使用中，抽閒產品和具體產品之間往往是多層次的產品結構，如下圖所示：

簡單工廠的實現（舉例）

#include <iostream>
#include <cstring>
#include <string>
using namespace std;

//定義具體產品的抽象父類
class Fruit
{
public:
    virtual    void getFruit() = 0;
};

//具體產品
class Banana : public Fruit
{
public:
    virtual void getFruit()
    {
        cout << "I am banana.."    << endl;
    }
};

class Apple : public Fruit
{
public:
    virtual void getFruit()
    {
        cout << "I am apple.." << endl;
    }
};
class Factory
{
public:
    Fruit *create(char *p)
    {
        if(strcmp(p,"apple") == 0)
        {
            return new Apple;
        }
        else if(strcmp(p,"banana") == 0)
        {
            return new Banana;
        }
        else
        {
            cout << "error" << endl;
            return NULL;
        }
    }
};

int main()
{
    Factory *f = new Factory;
    Fruit *fruit = NULL;

    char str[20];
    cout << "Please input (apple/banana)" << endl;
    cin >> str;
    fruit = f->create(str);
    fruit->getFruit();
    delete fruit;
    delete f;

    return 0;
}

簡單工廠模式的優缺點分析：

優點：工廠類是整個模式的關鍵所在。它包含必要的判斷邏輯，能夠根據外界給定的信息，決定究竟應該創建哪個具體類的對象。用戶在使用時可以直接根據工廠類去創建所需的實例，而無需瞭解這些對象是如何創建以及如何組織的。有利於整個軟件體系結構的優化。
缺點：由於工廠類集中了所有實例的創建邏輯，這就直接導致一旦這個工廠出了問題，所有的客戶端都會受到牽連；而且由於簡單工廠模式的產品室基於一個共同的抽象類或者接口，這樣一來，但產品的種類增加的時候，即有不同的產品接口或者抽象類的時候，工廠類就需要判斷何時創建何種種類的產品，這就和創建何種種類產品的產品相互混淆在了一起，違背了單一職責，導致系統喪失靈活性和可維護性。而且更重要的是，簡單工廠模式違背了“開放封閉原則”，就是違背了“系統對擴展開放，對修改關閉”的原則，因爲當我新增加一個產品的時候必須修改工廠類，相應的工廠類就需要重新編譯一遍。
總結一下：簡單工廠模式分離產品的創建者和消費者，有利於軟件系統結構的優化；但是由於一切邏輯都集中在一個工廠類中，導致了沒有很高的內聚性，同時也違背了“開放封閉原則”。另外，簡單工廠模式的方法一般都是靜態的，而靜態工廠方法是無法讓子類繼承的，因此，簡單工廠模式無法形成基於基類的繼承樹結構。