Chap3:创建型设计模式————工厂方法设计模式(下)

R_Jeff

上章讲的是创建型的设计模式,工厂方法(上),这次要讲的是另一本书关于工厂方法的一些概念以及案例、模型等等。就像电影“风雨哈佛路”中那个老师提问,为什么要用另外的一张一张纸质资料,而不直接用书籍。女主回答说,因为不同的资料汇集了不同人的思想。

工厂方法模式

假设你有一个关于个人事务管理的项目,功能之一是管理预约对象(Appointment)。现在要和另一个公司建立关系,需要一个叫做BloggsCal的格式来和他们交流预约相关的数据。但是你将来可能要面对更多的数据格式

在接口上可以立即定义两个类,

1.Class ApptEncoder:数据编码器,将Appointment转换成一个专有格式
2.Class CommsManager:管理员类,用来获取数据编码器,并使用编码器进行第三方通信

使用模型属于来描述的话,CommsManager就是创建者(Creator),而ApptEncoder是产品(product)
那么如何得到一个具体的ApptEncoder对象?

<?php
abstract class ApptEncoder{
    //产品类
    abstract function encode();
}
class BloggsApptEncoder extends ApptEncoder{
    //实际产品1
    function encode(){
        return "Appointment data encoded in BloggsCal Format\n";
    }
}
class MegaApptEncoder extends ApptEncoder{
  //实际产品2
    function encode(){
        return "Appointment data encoded in MegaCal Format\n";
    }
}
class CommsManager{
    //创建者(管理者)
    function getApptEncoder(){
        return new BloggsApptEncoder();
    }
}
?>

CommsManager类负责生成BloggsApptEncoder对象,但是当你和合作方关系改变,被要求转换系统来使用一个新的格式MegaCal时,那么代码就需要做另外的改变了

class CommsManager{
    const BLOGGS = 1;
    const MEGA = 2;
    private $mode =1;
    function __construct($mode){
        $this->mode = $mode;
    }
    function getApptEncoder(){
        switch($this->mode){
            case (self::MEGA):
                return new MegaApptEncoder();
            default:
                return new BloggsApptEncoder();
        }
    }
}
$comms = new CommsManager(CommsManager::MEGA);
$appt = $comms->getApptEncoder();
print $appt->encode();

在类中我们使用常量标志定义了脚本可能运行的两个模式:MEGA和BLOGGS,在getApptEncoder()方法中使用switch语句来检查$mode属性,并实例化相关编码器

但是这种方法还有一种小缺陷,通常情况下,创建对象需要指定条件,但是有时候条件语句会被当作Awful的“Code taste”,因为可能会导致重复的条件语句蔓延在代码中。我们知道创建者已经能够提供交流日历数据的功能,但是如果合作方要求提供页眉和页脚来约束每次预约,那该怎么办?

结果是,你需要在上面的代码中加入新的方法

function getHeaderText(){
      switch($this->mode){
            case (self::MEGA):
                return "This is Mega format header!\n";
            default:
                return "This is Bloggs format header!\n";
        }
}

Obviously,这会使得它在getApptEncoder()方法同时使用时,重复地使用了switch判断,一旦客户要增加其它需求,那工作量以及冗余程度会更重

总结一下当前需要思考的:
1.在代码运行时我们才知道要生成的对象类型(BloggsApptEncoder或者是MegaApptEncoder)
2.我们需要能够相对轻松地加入一些新的产品类型(如新的业务处理方式SyncML)
3.每一个产品类型都可定制特定的功能(如上文提到的页眉页脚)

另外注意我们使用的条件语句,其实可以被多态替代,而工厂方法模式恰好能让我们用继承和多态来封装具体产品的创建,黄菊花说,我们要为每种协议创建CommsManager的每一个子类,而每一个子类都要实现getApptEncoder方法

实现

工厂方法模式把创建者类与要生产的产品分离开来。创建者是一个工厂类,其中定义了用于生成产品对象的类方法,如果没有提供默认实现,那么就由创建者类的子类来执行实例化。一般来说,就是创建者类的每个子类实例化一个相应产品子类

所以我们把CommsManager重新指定为抽象类,这样就可以得到一个灵活的父类,并把所有特定协议相关的代码放到具体的子类中

下面是简化过的代码:

abstract class ApptEncoder{
    abstract function encode();
}
class BloggsApptEncoder extends ApptEncoder{
    function encode(){
        return "Appointment data encode in BloggsCal format!\n";
    }
}
abstract class CommsManager{
    abstract class getHeaderText();
    abstract class getApptEncoder();
    abstract class getFooterText();
}
class BloggsCommsManager extends CommsManager{
    function getHeaderText(){
        return "BloggsCal Header";
    }
     function getHeaderText(){
        return new BloggsApptEncoder();
    }
     function getFooterText(){
        return "BloggsCal Footer";
    }
   
}

现在当我们要求实现MegaCal时,只需要给CommsManager抽象类写一个新的实现
clipboard.png

注意到上面的创建者类与产品的层次结构很相似,这是使用工厂方法模式的常见结果,形成了一种特殊的代码重复。另一个问题是该模式可能会导致不必要的子类化,如果你为创建者创建子类的原因是为了实现工厂方法模式,那么最好再考虑一下(这就是为什么在例子中引入页眉页脚)

抽象工厂模式

上面例子中我们只关注了预约功能。
我们通过加入更多编码格式,使结构“横向”增长
如果想扩展功能,使其能够处理待办事宜和联系人,那应该让它进行纵向增长
clipboard.png

实现

CommsManager抽象类定义了用于生成3个产品(ApptEncoder、TtdEncoder、ContactEncoder)的接口,我们需要先实现一个具体的创建者,然后才能创建一个特定类型的具体产品,下图模型创建了BloggsCal格式的创建
clipboard.png

下面是CommsManager和BloggsCommsManager的代码

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";
    }
}

在这个例子中使用了工厂方法模式,getContactEncoder()是CommsManager的抽象方法,并在BloggsCommManager中实现。设计模式间经常会这样写作:一个模式创建可以把它自己引入到另一个模式的上下文环境中,我们加入了对MegaCal格式的支持

这样的模式带来了什么?
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_int);
    abstract function getFooterText();
}
class BloggsCommsManager extends CommsManager{
    function getHeaderText(){
        return "BloggsCal header";
    }
    function make($flag_int){
        switch($flag_int){
            case self::APPT:
                return new BloggsApptEncoder();
            case self::CONTACT:
                return new BloggsContactEncoder();
            case self::TTD:
                return new BloggsTtdEncoder();
        }
    }
    function getFooterText(){
        return "BloggsCal footer\n";
    }
}

类的接口更加紧凑,但也有代价,在使用工厂方法时,我们定义了一个清晰的接口强制所有具体工厂对象遵循它,而使用丹仪的make()方法,我们必须在所有的具体创建者中支持所有的产品对象。每个具体创建者都必须实现相同的标志检测(flag),客户类无法确定具体的创建者是否可以生成所有产品,因为make方法需要对每种情况进行考虑并进行选择


本章参考《深入PHP:面向对象、模式与实践》第9章

阅读 2.1k

网页狗修炼手册
大三狗正踏上web不归途

坚持拍黄片的大四网页狗要成为PHPer

405 声望
21 粉丝
0 条评论

坚持拍黄片的大四网页狗要成为PHPer

405 声望
21 粉丝
文章目录
宣传栏