本文實例講述了PHP設計模式之工廠模式（Factory）。分享給大家供大家參考，具體如下：
工廠模式的意思其實就是提供獲取某個對象實例的一個接口，同時使調用代碼避免確定實例化基類的步驟，實際上就是建立一個統一的類實例化的函數接口，完事統一調用，統一控制，它是PHP中常用的一種設計模式，一般會配合單例模式一起使用，來加載php類庫中的類。來看一個簡單的應用場景：
- 我們擁有一個Json類，String類，Xml類。
- 如果我們不使用工廠方式實例化這些類，則需要每一個類都需要new一遍，過程不可控，類多了，到處都是new的身影
- 引進工廠模式，通過工廠統一創建對象實例。
代碼如下：
?php
//工廠模式 提供獲取某個對象實例的一個接口，同時使調用代碼避免確定實例化基類的步驟
//字符串類
class String {
public function write() {}
}
//Json類
class Json {
public function getJsonData() {}
}
//xml類
class Xml {
public function buildXml() {}
}
//工廠類
class Factory {
public static function create($class) {
return new $class;
}
}
Factory::create("Json"); //獲取Json對象
我們現在應該對于工廠模式有了一個大概的理解了，咱們接下來可以從字面上來理解一下。
工廠么，它就是生產產品的地方，它有原料，設備和產品，那么在PHP中，我們可以理解為，這個工廠模式可以通過一個工廠類（設備），來調用自身的靜態方法（生產方式）來產生對象實例（產品），在上述實例中的Json類等，就相當于原料了。
理解了上面的一段話之后，我們就可以再深入的了解下這個工廠模式了。
我們來考慮以下場景，如果項目中，我們通過一個類創建對象，在快完成或者已經完成，要擴展功能的時候，發現原來的類的類名不是很合適或者發現類需要添加構造函數參數才能實現功能擴展，在這種情況下，大家就可以感受到“高內聚低耦合”的博大精深，我們可以嘗試使用工廠模式解決這個問題。
還有就是最經典的數據庫連接問題等等，都可以使用工廠模式來接覺問題，咱們也不廢話，來看一下網上一個比較經典的案例：
interface Transport{
public function go();
}
class Bus implements Transport{
public function go(){
echo "bus每一站都要停";
}
}
class Car implements Transport{
public function go(){
echo "car跑的飛快";
}
}
class Bike implements Transport{
public function go(){
echo "bike比較慢";
}
}
class transFactory{
public static function factory($transport)
{
switch ($transport) {
case 'bus':
return new Bus();
break;
case 'car':
return new Car();
break;
case 'bike':
return new Bike();
break;
}
}
}
$transport=transFactory::factory('car');
$transport->go();
大家有了解過工廠模式應該都知道，工廠模式有三種，那就是一般工廠模式（靜態工廠模式），工廠模式，還有就是抽象工廠模式，咱這里并未把所有的案例全部介紹完畢，不過嘞，咱們可以跟著網上的一個案例，來簡單了解下工廠模式的三種變形的過程。
首先，我們來假設有個關于個人事務管理的項目，功能之一就是管理Appointment(預約)對象。我們的業務團隊和A公司建立了關系，目前需要使用一個叫做BloggsCal格式來和他們交流預約相關的數據，但是業務部門提醒可能會有更多的數據格式，所以解碼器可能會有多種，我們呢，為了避免在邏輯代碼中使用過多的if else，可能就會需要使用工廠模式來將創造者和使用者分開。
那么，我們就需要兩個類，一個類AppEncoder用于定義一個解碼器，將A公司傳來的數據解碼；另外一個類CommsManager用于獲取該解碼器，就是調用AppEncoder類，用于與A公司進行通信。使用模式術語說，CommsManager就是創造者，AppEncoder就是產品（一個創造者、一個產品，將類的實例化和對象的使用分離開，這就是工廠模式的思想）。
咱們先來通過簡單工廠模式實現上述任務場景，如下：
//產品類
class BloggsApptEncoder {
function encode()
{
return "Appointment data encoded in BloggsCal format\n";
}
}
//創造者類
class CommsManager {
function static getBloggsApptEncoder()
{
return new BloggsApptEncoder();
}
}
大概明白了奧，好啦，現在又有新任務了，業務部門告訴我們需要新增一種數據格式MegCal，來完成數據交流，那么我們就需要新增對應的解碼器類，然后直接在commsManager新增參數來標識需要實例化哪個解碼器，如下：
class CommsManager {
const BLOGGS = 1;
const MEGA = 2;
private $mode;
public function __construct( $mode )
{
$this->mode = $mode;
}
function getApptEncoder()
{
switch($this->mode) {
case (self::MEGA):
return new MegaApptEncoder();
default:
return new BloggsApptEncoder();
}
}
}
上述兩個案例綜合起來就是簡單工廠模式了，它符合現實中的情況，而且客戶端免除了直接創建產品對象的責任，而僅僅負責“消費”產品（正如暴發戶所為）。
接下來，我們從開閉原則上來分析下簡單工廠模式，當新增一種數據格式的時候，只要符合抽象產品格式，那么只要通知工廠類知道就可以被使用了（即創建一個新的解碼器類，繼承抽象解碼器ApptEncoder），那么對于產品部分來說，它是符合開閉原則的——對擴展開放、對修改關閉，但是對于工廠類不太理想，因為每增加一各格式，都要在工廠類中增加相應的商業邏輯和判斷邏輯，這顯自然是違背開閉原則的。
然而在實際應用中，很可能產品是一個多層次的樹狀結構，這時候由于簡單工廠模式中只有一個工廠類來對應這些產品，所以這可能會把我們的上帝累壞了，因此簡單工廠模式只適用于業務簡單的情況下或者具體產品很少增加的情況，而對于復雜的業務環境可能不太適應了，這個時候就應該由工廠方法模式來出場了。
又來新需求了，那就是每種格式的預約數據中，需要提供頁眉和頁腳來描述每次預約。
咱們先來用簡單工廠模式來實現上述功能，如下：
// 簡單工廠模式
class CommsManager {
const BLOGGS = 1;
const MEGA = 2;
private = $mode;
public function __construct( $mode )
{
$this->mode = $mode;
}
// 生成解碼器對應的頁眉
public function getHeaderText()
{
switch( $this->mode ) {
case ( self::MEGA ):
return "MegaCal header\n";
default:
return "BloggsCal header\n";
}
}
// 生成解碼器
public function getApptEncoder()
{
switch( $this->mode ) {
case ( self::MEGA ):
return new MegaApptEncoder();
default:
return new BloggsApptEncoder();;
}
}
}
從上述代碼中，我們可以看到，相同的條件語句switch在不同的方法中出現了重復，而且如果添加新的數據格式，那么需要改動的類過多。所以需要對我們的結構進行修改，以求更容易擴展和維護。
我們可以使用創造者子類分別生成對應的產品，這樣添加新的數據格式時，只需要添加一個創造者子類即可，方便擴展和維護，這也就是比簡單工廠模式更復雜一點的工廠模式，如下：
// 工廠模式
abstract class CommsManager {
abstract function getHeaderText();
abstract function getApptEncoder();
abstract function getFooterText();
}
class BloggsCommsManager extends CommsManager {
function getHeaderText()
{
return "BloggsCal Header\n";
}
function getApptEncoder()
{
return new BloggsApptEncoder();
}
function getFooterText()
{
return "BloggsCal Footer\n";
}
}
class MegaCommsManager extends CommsManager {
function getHeaderText()
{
return "MegaCal Header\n";
}
function getApptEncoder()
{
return new MegaApptEncoder();
}
function getFooterText()
{
return "MegaCal Footer\n";
}
}
在這個時候，如果有新的數據格式，只需要添加一個創造類的子類即可，例如此時想獲取MegaCal對應的解碼器直接通過MegaCommsManager::getApptEncoder()獲取即可。
完了么？我只能說，這個實例還沒有完事。
新需求又來了，那就是不僅需要和A公司交流預約數據(Appointment)，還需要交流待辦事宜(Ttd)、聯系人(Contact)等數據，同樣的這些數據交流的格式也是BloggsCal和MegaCal，這個時候，我們可以直接在對應解碼器的子類中添加處理事宜(TtD)和聯系人(Contact)的方法，如下：
// 抽象工廠模式
abstract class CommsManager {
abstract function getHeaderText();
abstract function getApptEncoder();
abstract function getTtdEncoder();
abstract function getContactEncoder();
abstract function getFooterText();
}
class BloggsCommsManager extends CommsManager {
function getHeaderText()
{
return "BloggsCal Header\n";
}
function getApptEncoder()
{
return new BloggsApptEncoder();
}
function getTtdEncoder()
{
return new BloggsTtdEncoder();
}
function getContactEncoder()
{
return new BloggsContactEncoder();
}
function getFooterText()
{
return "BloggsCal Footer\n";
}
}
class MegaCommsManager extends CommsManager {
function getHeaderText()
{
return "MegaCal Header\n";
}
function getApptEncoder()
{
return new MegaApptEncoder();
}
function getTtdEncoder()
{
return new MegaTtdEncoder();
}
function getContactEncoder()
{
return new MegaContactEncoder();
}
function getFooterText()
{
return "MegaCal Footer\n";
}
}
//當然需要添加對應的TtdEncoder抽象類和ContactEncoder抽象類，以及他們的子類。
好啦，到這里就算是差不多結束了工廠模式的變形過程，我們可以來簡單歸納下這個變形過程中的核心，如下：
1.將系統和實現的細節分離開，我們可在示例中移除或者添加任意數目的編碼格式而不會影響系統。
2.對系統中功能相關的元素強制進行組合，因此，通過使用BloggsCommsManager，可以確定只使用與BloggsCal有關的類。
3.添加新產品時將會令人苦惱，因為不僅需要創建新產品的具體實現，而且為了支持它，我們必須修改抽象創建者和它的每個具體實現。
當然，我們可以創建一個標志參數來決定返回什么對象的單一的make()方法，而不用給每個工廠創建獨立的方法，如下：
abstract class CommsManager {
const APPT = 1;
const TTD = 2;
const CONTACT = 3;
abstract function getHeaderText();
abstract function make ( $flag_init );
abstract function getFooterText();
}
class BloggsCommsManager extends CommsManager {
function getHeaderText()
{
return "BloggsCal Header\n";
}
function make( $flag_init )
{
switch ($flag_init) {
case self::APPT:
return new BloggsApptEncoder();
case self::TTD:
return new BloggsTtdEncoder();
case self::CONTACT:
return new BloggsContactEncoder();
}
}
function getFooterText()
{
return "BloggsCal Header\n";
}
}
此時，如果還需要添加交流其它的數據，此時只需在抽象創造者中添加一個新的flag_init標識，并在子創造者中的make方法中添加一個條件，相比來說比原先的更加容易擴展，只需修改少數地方即可。
最后，來簡單總結下：
簡單工廠：適用于生成數量少，功能簡單的產品（BloggApptEncoder和MegaApptEncoder）
工廠模式：適用于生成數量多，功能復雜的產品（多個產品樹[BloggCal,MegaCal]、單個產品族[apptEncoder]），相比簡單工廠來說：業務更復雜，功能更多，但是產品族還是單個。
抽象工廠：適用于生成多個產品族、多個產品樹的情景(產品族[appt,ttd,contact]，產品樹[Bloggcal,megaCal])。相比于工廠模式，更容易擴展添加新的產品族
好啦，本次記錄就到這里了。
更多關于PHP相關內容感興趣的讀者可查看本站專題：《php面向對象程序設計入門教程》、《PHP數組(Array)操作技巧大全》、《PHP基本語法入門教程》、《PHP運算與運算符用法總結》、《php字符串(string)用法總結》、《php+mysql數據庫操作入門教程》及《php常見數據庫操作技巧匯總》
希望本文所述對大家PHP程序設計有所幫助。
您可能感興趣的文章:- php設計模式 Factory(工廠模式)
- 學習php設計模式 php實現工廠模式(factory)
- PHP設計模式之工廠模式(Factory Pattern)的講解
- PHP設計模式概論【概念、分類、原則等】
- PHP設計模式之 策略模式Strategy詳解【對象行為型】
- php設計模式 Template (模板模式)
- PHP常用的三種設計模式匯總
- php設計模式 DAO(數據訪問對象模式)
- PHP經典面試題之設計模式(經常遇到)
- PHP設計模式（一）工廠模式Factory實例詳解【創建型】
