2. 程式人生 > >設計模式：對象生成（單例、工廠、抽象工廠）

設計模式：對象生成（單例、工廠、抽象工廠）

阿新 • • 發佈：2018-03-14
添加 對象實例 log return ray 靜態 學習 線程 tco

對象的創建有時會成為面向對象設計的一個薄弱環節。我們可以使用多種面向對象設計方案來增加對象的創建的靈活性。
  • 單例模式：生成一個且只生成一個對象實例的特殊類
  • 工廠方法模式：構建創建者類的繼承層級
  • 抽象工廠模式：功能相關產品的創建

1. 單例模式

　　全局變量是面向對象程序員遇到的引發bug的主要原因之一。全局變量將類捆綁於特定的環境，破壞了封裝。如果新的應用程序無法保證一開始就定義了相同的全局變量，那麽一個依賴於全局變量的類就無法從一個應用程序中提取出來並應用到新的應用程序中。這些問題的產生也引發了單例模式的出現，保證一個類僅有一個實例，並提供一個訪問它的全局訪問點。

　　單例模式是最簡單的設計模式之一，也是被使用較多的設計模式。這種模式涉及到一個單一的類，該類負責創建自己的對象，同時確保只有單個對象被創建。這個類提供了一種訪問其唯一的對象的方式，可以直接訪問，不需要實例化該類的對象。

1 單例類對象可以被系統中的任何對象使用。
2 單例類對象不應該被儲存在會被覆寫的全局變量中。
3 單例類對象在系統中不應該超過一個。

　　首先，我們構建一個類 Preferences，先要求這個類無法從其自身外部來創建實例的類。實現這個只需定義一個私有的構造方法即可：

 class Preferences 
 {
     private $_props = array();
     
     private function __construct() {} // 禁止從外部創建類實例
     
     public function setProperty($key
 
, $val) {
         $this->_props[$key] = $val;
     }
     
     public function getProperty($key) {
         return $this->_props[$key];
     }
 }

　　現在這個類不能從外部類創建實例，但是內部也沒有對外提供獲取實例的方法，所以這個類是不能用的。這裏我們添加靜態方法和靜態屬性來間接實例化對象：

class Preferences
{
    private $_props = array();
    private
 
 static $_instance = null;

    private function __construct() {}

    public static function getInstance() {
        if (empty(self::$_instance)) {
            self::$_instance = new Preferences();
        }
        return self::$_instance;
    }

    public function setProperty($key, $val) {
        $this->_props[$key] = $val;
    }

    public function getProperty($key) {
        return $this->_props[$key];
    }
}

　　這是一個最基本的單例模式，我們可以通過靜態方法 getInstance 來獲取 Preferences 類的實例對象，同時能夠保證該對象在系統中是唯一的。測試一下：

$pref1 = Preferences::getInstance();
$pref1->setProperty(‘name‘, ‘bndong‘);
var_dump($pref1);

unset($pref1);

$pref2 = Preferences::getInstance();
var_dump($pref2);
var_dump($pref2->getProperty(‘name‘));

　　打印結果：

object(Preferences)[1]
  private ‘_props‘ => 
    array (size=1)
      ‘name‘ => string ‘bndong‘ (length=6)

object(Preferences)[1]
  private ‘_props‘ => 
    array (size=1)
      ‘name‘ => string ‘bndong‘ (length=6)

string ‘bndong‘ (length=6)

　　可以看到 $pref1 和 $pref2 的對象標識符相同，並且 $pref2 可以獲取到 $pref1 寫入的值，也就說明二者所指向的對象為一個。實現了單例模式的需求：

技術分享圖片

　註意：

  1. 上面實現單例模式使用的是PHP，所以不需要考慮線程安全的問題， Java 實現單例模式就需要考慮線程安全問題了，可以使用 synchronized 狀態修飾來進行控制，這裏我不過多贅述，想了解的可以去網上查閱。
  2. 在PHP中，所有的變量無論是全局變量還是類的靜態成員，都是頁面級的，每次頁面被執行時，都會重新建立新的對象，都會在頁面執行完畢後被清空。所以PHP單例模式我覺得只是針對單次頁面級請求時出現多個應用場景並需要共享同一對象資源時是非常有意義的。
  3. 單例和全局變量都可能被誤用。因為單例在系統任何地方都可以被訪問，所以它們可能會導致很難調試的依賴關系。如果改變一個單例，那麽所有使用該單例的類都會受到影響。在這裏，依賴本身不是問題。畢竟，我們在每次聲明一個有特定類型參數的方法時，也就創建了依賴關系。問題是，單例對象的全局化的性質會使程序員繞過類接口定義的通信線路。當單例被使用時，依賴便會被隱藏在方法內部，而並不會出現在方法聲明中。這使得系統中的依賴關系更加難以追蹤，因此需要謹慎小心地部署單例類。

　另外（無關緊要），由於項目畢竟是一個團隊開發，我在實現核心類的單例模式時候一般對類外加一些限制：

  1. 使用 final 對類進行限制，防止類被繼承或覆蓋。
  2. 私有化 __clone() 防止克隆。

2. 工廠方法模式

　　工廠方法模式也是一種常用的對象創建型設計模式，這種模式是用特定的類來處理實例化，通過依賴註入達到解耦，解決了當代碼關註於抽象類型時如何創建對象實例的問題。

　　工廠方法模式是對簡單工廠模式的改進，首先 簡單工廠模式：專門定義一個類用來負責創建其他類的實例，被創建的實例通常都具有共同的父類。

abstract class ApptEncoder
{
    abstract function encode();
}

class BloggsApptEncoder extends ApptEncoder 
{
    public function encode()
    {
        // TODO: Implement encode() method.
    }
}

class MegaApptEncoder extends ApptEncoder 
{
    public function encode()
    {
        // TODO: Implement encode() method.
    }
}

class CommsManager
{
    const BLOGGS = 1;
    const MEGA   = 2;
    
    private $_mode = 1;
    
    public function __construct($mode)
    {
        $this->_mode = $mode;
    }


    public function getApptEncoder()
    {
        switch ($this->_mode) {
            case self::BLOGGS :
                return new MegaApptEncoder();
            default:
                return new BloggsApptEncoder();
        }
    }
}

$comms = new CommsManager(CommsManager::BLOGGS);
$apptEncoder = $comms->getApptEncoder();
$apptEncoder->encode();

技術分享圖片

　　我們通過簡單工廠模式的結構可以發現：（適用於工廠類負責創建對象較少的情形）

  1. 工廠類中包含了所有實例的創建邏輯，一旦這個工廠不能工作，整個系統都會受到影響。
  2. 違背開放關閉原則，一旦添加新的工廠子類就不得不修改工廠類的邏輯。
  3. 如果添加新的方法會迫使我們要重復使用條件判斷語句，維護麻煩，而且當條件語句蔓延到代碼中，我們不應該感到樂觀。

　　為了解決這些問題，衍生出了設計模式：工廠方法模式。

　　工廠方法模式的工廠類，不再負責所有類的實例創建，不會因為添加新的工廠子類而修改工廠類的邏輯，符合開放閉合原則。

　　把 CommsManager 重新制定為抽象類。這樣可以得到一個靈活的父類，並把所有特定協議相關代碼方法具體的子類中：

abstract class ApptEncoder
{
    abstract function encode();
}

class BloggsApptEncoder extends ApptEncoder
{
    public function encode()
    {
        // TODO: Implement encode() method.
    }
}

class MegaApptEncoder extends ApptEncoder
{
    public function encode()
    {
        // TODO: Implement encode() method.
    }
}

abstract class CommsManager
{
    abstract function getA();
    abstract function getB();
    abstract function getApptEncoder();
}

class BloggsCommsManger extends CommsManager
{
    public function getA()
    {
        // TODO: Implement getA() method.
    }

    public function getB()
    {
        // TODO: Implement getB() method.
    }

    public function getApptEncoder()
    {
        return new BloggsApptEncoder();
    }
}

class MegaCommsManger extends CommsManager
{
    public function getA()
    {
        // TODO: Implement getA() method.
    }

    public function getB()
    {
        // TODO: Implement getB() method.
    }

    public function getApptEncoder()
    {
        return new MegaApptEncoder();
    }
}

技術分享圖片

　　這裏簡單介紹下上面代碼的結構，理解了的請略過

  • 工廠類：CommsManager 用於定義工廠子類
  • 工廠子類：MegaCommsManager、BloggsCommsManager 用於創建每個產品對象
  • 產品類：ApptEncoder 用於定義產品子類
  • 產品子類：MegaApptencoder、BloggsApptEncoder

　　可以看到在工廠類中增加了兩個方法：getA，getB。這也是工廠方法模式所適用的一種情形， 如果只為創建子類就實現工廠方法模式就需要再考慮下了。套用我上級老大的一句話：永遠不要為了模式而模式。

　　工廠方法模式，解決了許多簡單工廠模式的問題，遵循開放閉合原則，可擴展。但是這種模式也形成了一種特殊的代碼重復，因而不被一些人喜歡。並且添加新產品時，處理增加新“產品”類外，還要提供與之對應的具體工廠類，系統類的個數成對增加。工廠方法模式可以解決類的橫向擴展，對於類的縱向擴展並不能有效解決，這也就引出了抽象工廠模式。

3. 抽象工廠模式

　　抽象工廠解決了工廠方法縱向擴展問題，例如我們縱向增加了一些類：

　技術分享圖片

　　如果使用工廠方法模式來實現

abstract class CommsManager
{
    abstract function getA();
    abstract function getB();
    abstract function getApptEncoder();
    abstract function getTtdEncoder();
    abstract function getContactEncoder();
}

class BloggsCommsManger extends CommsManager
{
    public function getA()
    {
        // TODO: Implement getA() method.
    }

    public function getB()
    {
        // TODO: Implement getB() method.
    }

    public function getApptEncoder()
    {
        return new BloggsApptEncoder();
    }
    
    public function getTtdEncoder()
    {
        return new BloggsTtdEncoder();
    }
    
    public function getContactEncoder()
    {
        return new BloggsContactEncoder();
    }
}

技術分享圖片

　　上面是使用工廠方法模式來實現的類圖，有沒有感覺這個模式一旦添加了新產品維護起來特別的麻煩，因為不僅要創建新產品的具體實現，而且為了支持它，還必須修改抽象創建者和它的每一個具體實現。

　　這種時候應該使用抽象工廠模式，抽象工廠模式是對工廠進行一次抽象。統一對象的獲取接口，使用參數來決定返回的對象。修改下：（ps：感覺就是使用簡單工廠模式對工廠方法模式再進行一次抽象）

abstract class CommsManager
{
    const APPT    = 1;
    const TTD     = 2;
    const CONTACT = 3;
    
    abstract function getA();
    abstract function getB();
    abstract function make($flg);
}

class BloggsCommsManger extends CommsManager
{
    public function getA()
    {
        // TODO: Implement getA() method.
    }

    public function getB()
    {
        // TODO: Implement getB() method.
    }

    public function make($flg)
    {
        switch ($flg) {
            case self::APPT:
                return new BloggsApptEncoder();
            case self::TTD:
                return new BloggsTtdEncoder();
            case self::CONTACT:
                return new BloggsContactEncoder();
            default:
                return new BloggsApptEncoder();
        }
    }
}

技術分享圖片

　　可以看到所有創建對象接口統一到 make() 方法，接口變得更加緊湊。但是這樣也暴露出了一些簡單工廠模式的弊端，如開放閉合原則。使用抽象工廠模式會使工廠類更容易維護，基類 CommsManager 可以提供默認的 make() 實現，子類可以實現自己的調用基類的。

　　關於工廠方法和抽象工廠的區別：

  1. 工廠方法產出的是產品（實例），抽象工廠產出是接口（創建每個實例的接口）
  2. 工廠方法是產出單一對象，抽象工廠產出是一系列相關產品的對象

技術分享圖片

　　關於工廠方法和抽象工廠的適用：無論是什麽樣的設計模式，最切合當前業務場景的就是最適用的。個人理解，如果我們的產品是，奔馳、寶馬、五菱宏光之類單一類別產品就比較適用工廠方法模式。但是有一天我們的產品除了汽車還需要添加華碩、聯想、惠普等另一種類別產品的時候就要考慮使用抽象工廠模式了。抽象工廠方法更適用於對產品族的處理。

4. 結語

　　終於抽出時間學習設計模式了o(╥﹏╥)o，邊學習邊寫隨筆，寫東西有助於更好理解。好的設計模式運用能使整體代碼結構更清晰，維護擴展性更高。感謝閱讀！再會！

設計模式：對象生成（單例、工廠、抽象工廠）

相關推薦

設計模式：對象生成（單例、工廠、抽象工廠）

添加 對象實例 log return ray 靜態 學習 線程 tco 對象的創建有時會成為面向對象設計的一個薄弱環節。我們可以使用多種面向對象設計方案來增加對象的創建的靈活性。 單例模式：生成一個且只生成一個對象實例的特殊類 工廠方法模式：構建創建者類的繼承層級

[設計模式][面向對象]單例模式

inversion 使用 實例化 占用 開閉 final spa logs 修改 設計模式遵循的原則有6個： 1、開閉原則（Open Close Principle） 　　對擴展開放，對修改關閉。 2、裏氏代換原則（Liskov Substitution Princi

設計模式-面向對象設計原則

子類 align ron 關閉 composite 接口 其他 res dep 七種常用的面向對象設計原則 單一職責原則（Single Responsibility Principle,SRP）： 　　　　一個類只負責一個功能領域中的相應職責。 開閉原則（Open-C

設計模式——面向對象設計原則

指導 軟件設計 就會 3.5 做到 實現 分析 3.1 需求 設計模式——面向對象設計原則 1.什麽是面向對象設計 世界是具體的，認知是抽象的。像自然界中的生物、植物、動物一個個名詞，就是對一系列具體個體抽象出來的稱謂，而魚、老虎、樹等就是一個個實在的具體。哦，也許你會說

java 設計模式（單例，享元，策略）

讀書不覺已春深，一寸光陰一寸金。 java的設計模式大體上分為三大類： 建立型模式（5種）：工廠方法模式，抽象工廠模式，單例模式，建造者模式，原型模式。 結構型模式（7種）：介面卡模式，裝飾器模式，代理模式，外觀模式，橋接模式，組合模式，享元模式。

設計模式：物件去耦（中介者，觀察者）

為了嚴格遵循MVC，MVVM等架構模式，經常需要物件去耦。 10、中介者模式：用一個物件來封裝一系列物件的互動方式。中介者使各物件不需要顯示地相互引用，從而使其耦合鬆散，而且可以獨立地改變它們之間的

Java核心類庫-IO-對象流（實現序列化與反序列化）

.get throws 反序 code row cts new java cep 使用對象流來完成序列化和反序列化操作： 　　ObjectOutputStream：通過writeObject()方法做序列化操作的 　　ObjectInputStream：通過readObje

設計模式 _第一招式_單例模式

一、定義 單例模式（Singleton Pattern）是一個比較簡單的模式，確保某一個類只有一個例項，而且自行例項化並向整個系統提供這個例項。 二、程式碼演示 Singleton 類稱為單例類，通過使用private的建構函式確保在一個應用中只產生一個例項，並且自行例項化，單例

java設計模式中的5種寫單例的方式

第一種（懶漢，執行緒不安全）： Java程式碼   public class Singleton {      private static Singleton instance;      private Singleton (){}      public 

Android設計模式系列(3)--SDK原始碼之單例模式

單例模式，可以說是GOF的23種設計模式中最簡單的一個。這個模式相對於其他幾個模式比較獨立，它只負責控制自己的例項化數量單一(而不是考慮為使用者產生什麼樣的例項)，很有意思，是一個感覺上很乾淨的模式，本人很喜歡這個模式。android中很多地方都用到了單例模式，本文以輸入法管理者InputMethodMan

JavaScript設計模式：一、面向對象編程（第二節）

得到 調用 帶來 方式 get 特權 style 方法封裝 面向對象 一、封裝 面向對象編程思想其中的一個特點就是封裝，通俗的講法就是把需要的功能方向在一個對象裏。遺憾的是，對於JS這種解釋性的弱類型語言沒有經典強類型語言中那樣通過class等關鍵字實現類的封裝方法，j

JavaScript設計模式：一、面向對象編程（第三節）

設置 style 擁有 ray 進行 如果 eat gree 而在 一、繼承 js並沒有繼承這一個現有的機制，所以我們所說的繼承是通過JS本身的機制去實現的。 1、類式繼承 1 // 類式繼承 2 3 // 父類 4 function SuperClas

JavaScript設計模式：一、面向對象編程

this 依賴 人在 turn obj log javascrip 體會 創建 JavaScript面向對象編程 眾所周知，JS作為一門腳本語言，由於其設計者在設計JS的時候，也僅僅用了很少的時間就完成了JS這門語言的創建，JS雖然擁有著腳本語言的優勢，但是JS也存在著

添磚加瓦：設計模式（單例模式）

argv pri 方法 職責 ger 資源管理 存在 優缺點 names 　　1、單例定義及要素 　　定義： 　　保證一個類只有一個實例存在，同時提供能對該實例加以訪問的全局訪問方法（GoF中單例模式的定義）。 　　要素： 　　（1）某個類只能有一個實例 　　（2）必須自行

設計模式：單例模式（餓漢）

/** * 單例模式。 * @author Bright Lee */ public class HungrySingleton { private static final HungrySingleton instance = new HungrySingleton();

設計模式：單例模式（懶漢）

/** * 單例模式。 * @author Bright Lee */ public class LazySingleton { private static volatile LazySingleton instance; private LazySingleton() {

【JAVA】基礎：設計模式（單例設計模式，工廠設計模式）

設計模式：解決某一類問題最行之有效的方法。 java中有23種設計模式。 建立型模式（5種）：工廠方法模式，抽象工廠模式，單例模式，建造者模式，原型模式。 結構型模式（7種）：介面卡模式，裝飾器模式，代理模式，外觀模式，橋接模式，組合模式，享元模式。 行為型模式（11種）：策略模式、模板方法

設計模式：這是最全面 & 詳細的 單例模式（Singleton）分析指南

前言 今天我來全面總結一下Android開發中最常用的設計模式 - 單例模式。 關於設計模式的介紹，可以看下我之前寫的：1分鐘全面瞭解“設計模式” 目錄 1. 例項引入 背景：小成有一個塑料生產廠，但裡面只有一個倉庫。 目的：

java設計模式：面向對象設計的7個原則

ron 依賴倒置原則 步驟 計算機 適應性 抽象類 oops 關閉 sla 在軟件開發中，為了提高軟件系統的可維護性和可復用性，增加軟件的可擴展性和靈活性，程序員要盡量根據7條原則來開發程序，從而提高軟件開發效率，節約軟件開發成本和維護成本。 這7條原則分別是：開閉原則、

設計模式：單例模式（Singleton）

  單例模式在23個設計模式中算得上是最簡單的一個了，也許你會有異議，那就換成“最簡單之一”，這樣就嚴謹了很多。   單例模式：保證一個類僅有一個例項，並提供一個訪問它的全域性訪問點。   適用性：當類只能有一個例項而且客戶可以從一個眾所周知的訪問點訪問它時