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