摘要：很多接觸的框架就是基于各種模式設計形成的。在所有模式設計中，有三種基礎設計模式，單例模式，工廠模式，注冊樹模式，其他模式往往基于這幾種模式，今天帶來的是單例模式。工廠模式更多考慮的是擴展維護的問題。

（非原創(chuàng)）

一.單例模式

模式設計是什么？初學者一開始會被這高大上的名稱給唬住。而對于有豐富編程經(jīng)驗的老鳥來說，模式設計又是無處不在。很多接觸的框架就是基于各種模式設計形成的。 簡單說，在寫代碼的過程中一開始往往接觸的是面向過程的，簡單的基礎的編程。這個時候我們往往追求的是代碼能夠實現(xiàn)某項功能就萬事大吉。管他代碼多么冗余，管他代碼是否可重用，管他效率如何，能實現(xiàn)功能就好。但是，真正應用于實際的，更被大家采納的是那些高效的，可重用的，便于團隊開發(fā)的代碼。基于這些因素，你不能像練手一樣，隨便命名函數(shù)名，隨便放置腳本。模式設計告訴是給人們組織代碼提供一種思路，實現(xiàn)可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。

　　在所有模式設計中，有三種基礎設計模式，單例模式，工廠模式，注冊樹模式，其他模式往往基于這幾種模式，今天帶來的是單例模式。

　　什么是單例模式？

　　根據(jù)這個名稱，我們很容易了解到，單例模式指的是在整個應用中只有一個對象實例的設計模式。

　　為什么要用單例模式？

　　php常常和數(shù)據(jù)庫打交道，如果在應用中如果頻繁建立連接對象，進行new操作的話，會消耗大料的系統(tǒng)內存資源，這并不是我們希望看到的。再則，在團隊合作項目中，單例模式可以有效避免不同程序員new自己的對象，造成人為的系統(tǒng)消耗。

　如何建立單例模式？

　　在看到這個問題的時候，相信優(yōu)秀的程序員很可能自己試著根據(jù)要求去創(chuàng)建單例模式，而不是坐等前人的經(jīng)驗。區(qū)別于其他博友告訴你什么樣的模式是單例模式，我人更愿意和有面向對象編程基本經(jīng)驗的你考慮一下如何自己建立單例模式。

　　我們首先從題目出發(fā)，單例模式是只有一個對象實例的設計模式。這一點是很讓人蛋疼的。我們平常創(chuàng)建的類不是能創(chuàng)建很多對象的，就是不能創(chuàng)建對象的（抽象類）。要創(chuàng)建對象需要有類這是必須的，而且不能是抽象類。這個類要防止別人可以多次創(chuàng)建函數(shù)。我們自然而然考慮到了從構造函數(shù)入手。但是，每次new操作都會調用構造函數(shù)，也就是會多次創(chuàng)建對象實例。這和我們設計初衷相悖了。在此處務必申明構造函數(shù)為private或者protected這樣才能解決這個問題。

　　構造函數(shù)被申明為private或者protected這注定無法通過new的方法創(chuàng)建實例對象了。而且我們發(fā)現(xiàn)，經(jīng)過這一步處理后，解決問題的前景變得明朗起來了。為什么呢？既然無法通過new方法創(chuàng)建對象實例，那么我們只能通過類內的方法來創(chuàng)建對象實例了。 這個時候我們面臨一個有趣的先有雞還是先有蛋的問題。我們往往往往是創(chuàng)建了對象后才調用對象的方法，而此時需要調用類里面的方法來創(chuàng)建對象。不受是否創(chuàng)建對象影響都能調用的方法的解決方案毋庸置疑那就是利用關鍵字--static。

　　在類內創(chuàng)建靜態(tài)方法完成完成什么工作呢？回歸主題：確保只創(chuàng)建一個實例對象。如何確保只有一個呢？這很簡單，if判斷一下啊。存在的話直接返回，不存在自己創(chuàng)建一個嘛。當然這個實例對象是類的靜態(tài)屬性。至此，單例模式要求的功能實現(xiàn)完成。真的完成了么?還不算~如果有個類繼承本類，將構造方法申明為public那不又壞事兒了？那有必要在構造方法前加final關鍵字了。

　　最后貼上單例模式代碼，代碼解釋都在上面了~~

hash=rand(1,9999);
    }

    static public function getInstance(){
        if (self::$ins instanceof self) {
            return self::$ins;
        }
        self::$ins=new self();
        return self::$ins;
    } 
}

本身單例模式并不復雜，但需要深入理解。很多初學者依舊會感嘆：臥槽，構造方法原來不一直是public啊~臥槽還可以不通過new創(chuàng)建對象啊~其實筆者想說，不管構造方法被申明為public，private還是protected，最終創(chuàng)建對象的時候都會調用。一直是new創(chuàng)建對象實例，單例模式也用new創(chuàng)建對象，只是換個地方而已，從類外到類內。

二.工廠模式

那么何為工廠模式？

　　從名字來看，似乎看不出什么端倪。工廠模式，和生產有關？還是和生產流程有關？難道還和工廠領導有關？和領導秘書有關？秘書... 好了不賣關子了，所謂工廠模式還真和生產有關。生產什么呢？生產出來的是一個實例對象。通過什么設備生產？通過一個工廠類生產。怎么生產呢？工廠類調用自身靜態(tài)方法來生產對象實例。

　工廠模式有一個關鍵的構造，根據(jù)一般原則命名為Factory的靜態(tài)方法，然而這只是一種原則，雖然工廠方法可以任意命名這個靜態(tài)還可以接受任意數(shù)據(jù)的參數(shù)，必須返回一個對象。

　　為什么要用工廠模式？

　　很多沒接觸過工廠模式的人會不禁問，為啥我要費那么大的勁兒去構造工廠類去創(chuàng)建對象呢？不去套用那些易維護，可擴展之類的話，我們可以考慮這樣一個簡單的問題。如果項目中，我們通過一個類創(chuàng)建對象。在快完成或者已經(jīng)完成，要擴展功能的時候，發(fā)現(xiàn)原來的類類名不是很合適或者發(fā)現(xiàn)類需要添加構造函數(shù)參數(shù)才能實現(xiàn)功能擴展。我靠！我都通過這個類創(chuàng)建了一大堆對象實例了啊，難道我還要一個一個去改不成？我們現(xiàn)在才感受到了“高內聚低耦合”的博大精深。沒問題，工廠方法可以解決這個問題。

　　再考慮一下，我要連接數(shù)據(jù)庫，在php里面就有好幾種方法，mysql擴展，mysqli擴展，PDO擴展。我就是想要一個對象用來以后的操作，具體要哪個，視情況而定嘍。既然你們都是連接數(shù)據(jù)庫的操作，你們就應該擁有相同的功能，建立連接，查詢，斷開連接...（此處顯示接口的重要性）。總而言之，這幾種方法應該“團結一致，一致對外”。如何實現(xiàn)呢？利用工廠模式。

　　工廠模式如何實現(xiàn)？

　　相對于單例模式，上面我們提供了足夠的信息，工廠類，工廠類里面的靜態(tài)方法。靜態(tài)方法里面new一下需要創(chuàng)建的對象實例就搞定了。當然至于考慮上面的第二個問題，根據(jù)工廠類靜態(tài)方法的參數(shù)，我們簡單做個判斷就好了。管你用if..else..還是switch..case..，能快速高效完成判斷該創(chuàng)建哪個類的工作就好了。最后，一定要記得，工廠類靜態(tài)方法返回一個對象。不是兩個，更不是三個。

基本的工廠類

//要創(chuàng)建對象實例的類
class MyObject{
  
}
 //工廠類
class MyFactory{
public static function factory(){
return new MyObject():
   }
}
 
 
$instance=MyFactory::factory();

稍微復雜點的工廠類

    go();

需要工廠靜態(tài)方法為factory()的時候，千萬別再傻乎乎的把工廠類命名為Factory了。為啥啊？別忘了同名構造函數(shù)的事兒啊~
　　最后還是談點感受吧，很多新手比較眼高手低，剛剛會了if..else..，session,cookie就要來點高大上的了。與人交談動輒可擴展性，可維護性之類云云，至于實例的話，就會一時語塞。有時候覺得，無論自己寫代碼還是和別人學習，都處于“眾里尋他千百度”的時候，真正踏實學習后，驀然回首，“那人卻在燈火闌珊處”，大呼：“原來這TM就是*啊”。

三.注冊樹模式

什么是注冊樹模式？

　　注冊樹模式當然也叫注冊模式，注冊器模式。之所以我在這里矯情一下它的名稱，是因為我感覺注冊樹這個名稱更容易讓人理解。像前兩篇一樣，我們這篇依舊是從名字入手。注冊樹模式通過將對象實例注冊到一棵全局的對象樹上，需要的時候從對象樹上采摘的模式設計方法。 這讓我想起了小時候買糖葫蘆，賣糖葫蘆的將糖葫蘆插在一個大的桿子上，人們買的時候就取下來。不同的是，注冊樹模式摘下來還會有，能摘很多次，糖葫蘆摘一次就沒了。。。

　　為什么要采用注冊樹模式？

　　單例模式解決的是如何在整個項目中創(chuàng)建唯一對象實例的問題，工廠模式解決的是如何不通過new建立實例對象的方法。 那么注冊樹模式想解決什么問題呢？ 在考慮這個問題前，我們還是有必要考慮下前兩種模式目前面臨的局限。 首先，單例模式創(chuàng)建唯一對象的過程本身還有一種判斷，即判斷對象是否存在。存在則返回對象，不存在則創(chuàng)建對象并返回。 每次創(chuàng)建實例對象都要存在這么一層判斷。 工廠模式更多考慮的是擴展維護的問題。 總的來說，單例模式和工廠模式可以產生更加合理的對象。怎么方便調用這些對象呢？而且在項目內如此建立的對象好像散兵游勇一樣，不便統(tǒng)籌管理安排啊。因而，注冊樹模式應運而生。不管你是通過單例模式還是工廠模式還是二者結合生成的對象，都統(tǒng)統(tǒng)給我“插到”注冊樹上。我用某個對象的時候，直接從注冊樹上取一下就好。這和我們使用全局變量一樣的方便實用。 而且注冊樹模式還為其他模式提供了一種非常好的想法。

　　如何實現(xiàn)注冊樹？

　　通過上述的描述，我們似乎很容易就找到了解決方法。首先我們需要一個作為注冊樹的類，這毋庸置疑。所有的對象“插入”到注冊樹上。這個注冊樹應該由一個靜態(tài)變量來充當。而且這個注冊樹應該是一個二維數(shù)組。這個類應該有一個插入對象實例的方法（set()），當讓相對應的就應該有一個撤銷對象實例的方法（_unset()）。當然最重要的是還需要有一個讀取對象的方法（get()）。擁有這些，我們就可以愉快地完成注冊樹模式啦~~~

　　下面讓三種模式做個小小的結合。單純創(chuàng)建一個實例對象遠遠沒有這么復雜，但運用于大型項目的話，便利性便不言而喻了。

hash=rand(1,9999);
    }

    static public function getInstance(){
        if (self::$ins instanceof self) {
            return self::$ins;
        }
        self::$ins=new self();
        return self::$ins;
    } 
}

//工廠模式
class RandFactory{
    public static function factory(){
        return Single::getInstance();
    }
}

//注冊樹
class Register{
    protected static $objects;
    public static function set($alias,$object){
        self::$objects[$alias]=$object;
    }
    public static function get($alias){
        return self::$objects[$alias];
    }
    public static function _unset($alias){
        unset(self::$objects[$alias]);
    }
}

Register::set("rand",RandFactory::factory());

$object=Register::get("rand");

print_r($object);

至此，三種模式設計介紹完畢。各種模式設計本身就會相輔相成，往后介紹其他模式的時候，多多少少會用到一種或多種其他設計模式。

　　一種模式不懂不要緊，相信編程的深入，定會產生恍然大悟的驚喜感 ，愿諸君與我共進步。