用工廠方法或者類來例項化物件，而不是直接new。
首先我們需要建立一個工廠類，比如Factory.php。如果不使用工廠模式的，我們需要一個物件的時候通常需要
new Inexistence\girlfriend();
然而我們一般不只在一個地方需要這個物件，這個時候一旦物件發生變更，或者物件的某些屬性發生變化，我們就需要一個一個的來改，非常麻煩。這個時候我們引入工廠類，在Factory.php中

<?php
namespace Imagination;

class Factory
{
    static function getGirlfriend()
 

    {
        $GF = new girlfriend;
        return $GF;
    }
}

然後每次呼叫時$GF1 = Imagination\Factory::getGirlfriend()就可以避免四處修改的問題。
在Laravel中這樣的設計模式很常見。

class CommentsController extends Controller {

    /**
     * Store a newly created resource in storage.
     *
     * @return Response
     */
 

    public function store()
    {
        if (Comment::create(Input::all())) {
            return Redirect::back();
        } else {
            return Redirect::back()->withInput()->withErrors('Fail to comment!');
        }
    }

}

這段工廠模式描述的比較簡單，找到了laravel學院的一片文章 和 GIT 的一篇英文文章。

學院君的舉例可以很快的理解。如下：

出現的問題
舉個例子，如果某個應用是可移植的，那麼它需要封裝平臺依賴，這些平臺可能包括視窗系統、作業系統、資料庫等等。這種封裝如果未經設計，通常程式碼會包含多個 if 條件語句以及對應平臺的操作。這種硬編碼不僅可讀性差，而且擴充套件性也不好。

解決的思路
提供一個間接的層（即“抽象工廠”）抽象一組相關或依賴物件的建立而不是直接指定具體實現類。該“工廠”物件的職責是為不同平臺提供建立服務。客戶端不需要直接建立平臺物件，而是讓工廠去做這件事。
這種機制讓替換平臺變得簡單，因為抽象工廠的具體實現類只有在例項化的時候才出現，如果要替換的話只需要在例項化的時候指定具體實現類即可。

學院君圖解

GIT分析圖解

laravel學院的這個工程模式有一些沒看懂，關於PHPUnit 的一些函式 assertContainsOnly()，還有就是 phpunit 根據這個標誌 @dataProvider getFactories，獲取getFactories方法返回的資料分別傳入該方測試方法中除錯。是不是固定寫法。