设计模式-组合模式

组合模式将对象组合成树形结构,以表示‘部分-整体’的层次结构。

在组合模式,客户端访问独立对象和组合对象(或称对象集合)一样

独立对象是一个有特定功能的对象,它不引用其他任何其他对象。

组合对象则是一个提供相似功能对象集合,主要用来管理独立对象,并为客户端提供和独立对象一样的访问方式。

接下来,我们就以目录和文件来举例,利用它们的一个相同的功能“查看大小”来举例。

1 问题

在文件系统中,我们有文本文件、图片文件、视频文件等类型的文件。

它们格式不同,但都有容量大小。

现在,我们创建文本和图片文件两个类,且各自有固定的大小。

(实际当然不是如此,这里举例所以简化处理。)

接着,我们要获取文件和目录的大小。

首先是文件:

abstract class File
{
    abstract function getSize();
}

class TextFile extends File
{
    public function getSize()
    {
        return 2;
    }
}

class ImageFile extends File
{
    public function getSize()
    {
        return 100;
    }
}

这样,在创建文本或图片对象后,就可以通过getSize()方法获取到它们的大小。

然后,我们创建一个目录类,它可以把文件组合起来

class Dir
{
    private $files = [];

    // 传入参数必须为File文件对象
    public function addFile(File $file)
    {
        $this->files[] = $file;
    }

    public function getSize()
    {
        $size = 0;
        foreach ($this->files as $file) {
            $size += $file->getSize();
        }

        return $size;
    }
}

然后,我们就可以计算目录的大小,它等于目录下所有文件大小之和。

例如,这个目录加入一个文本文件,一个图片文件,那么这个目录大小就是:102

当然,如果问题一直这样简单的话,那么这个模型还是非常令人满意的。

但是,如果有一些新的需求加入会怎样?

比如,要在目录中再加一层目录,那么Dir类就需要变成:

class NewDir
{
    private $files = [];
    private $dirs = [];

    public function addFile(File $file)
    {
        $this->files[] = $file;
    }

    public function addDir(NewDir $newDir) {
        $this->dirs = $newDir;
    }

    public function getSize()
    {
        $size = 0;
        foreach ($this->files as $file) {
            $size += $file->getSize();
        }

        foreach ($this->dirs as $dir) {
            $size += $dir->getSize();
        }

        return $size;
    }
}

是不是比之前又复杂了些?

这还不算,我们还需要修改原来的类,可能无意间又影响原来的功能 。

另外,如果我们现在要计算多级子目录的大小、或者从目录中删除目录,是不是还需要修改原有类?

显然,这个模型无法实现这些复杂的功能,我们需要一个更加灵活的模型。

2 组合模式

组合模式的解决方法是,用抽象类规范统一的对外接口。

然后,让文件类和目录类实现这个接口,并在目录类中递归计算文件的大小

同时,目录类比文件类两个方法:add()remove(),用以管理文件对象。

这样,目录类就能用同样的方式获取自身的大小。

并且,还能灵活从目录总增删子目录和文件。

2.1 接口

接口用于规范独立对象和组合对象,保证能够对外提供一致性的使用方法。

这里以getName()getSize()方法为例:

/**
 * 规范独立对象和组合对象必须实现的方法,保证它们提供给客户端统一的
 * 访问方式
 */
abstract class Filesystem
{
    protected $name;

    public function __construct($name)
    {
        $this->name = $name;
    }

    public abstract function getName();
    public abstract function getSize();
}

其中,__construct构建函数用于传入文件或目录名称,并非必须。

这个接口中规范的方法要根据需求来定义,并且同时要考虑独立对象拥有的功能

如果独立对象之间有差异的功能,不适合聚合在一起,则不能放在组合类中。

2.2 目录类

目录类是对象集合,通过add()remove()方法管理文件对象和其他目录对象

目录类也需要实现抽象类中的方法,以提供给客户端一致性的使用方式。

/**
 * 目录类
 */
class Dir extends Filesystem
{
    private $filesystems = [];

    // 组合对象必须实现添加方法。因为传入参数规定为Filesystem类型,
    // 所以目录和文件都能添加
    public function add(Filesystem $filesystem)
    {
        $key = array_search($filesystem, $this->filesystems);
        if ($key === false) {
            $this->filesystems[] = $filesystem;
        }
    }

    // 组合对象必须实现移除方法
    public function remove(Filesystem $filesystem)
    {
        $key = array_search($filesystem, $this->filesystems);
        if ($key !== false) {
            unset($this->filesystems[$key]);
        }
    }

    public function getName()
    {
        return '目录:' . $this->name;
    }

    public function getSize()
    {
        $size = 0;
        foreach ($this->filesystems as $filesystem) {
            $size += $filesystem->getSize();
        }

        return $size;
    }
}

2.3 文件类

文件类实现具体的功能,但是没有add()remove()方法。

/**
 * 独立对象:文本文件类
 */
class TextFile extends Filesystem
{
    public function getName()
    {
        return '文本文件:' . $this->name;
    }

    public function getSize()
    {
        return 10;
    }
}

/**
 * 独立对象2:图片文件类
 */
class ImageFile extends Filesystem
{
    public function getName()
    {
        return '图片:' . $this->name;
    }

    public function getSize()
    {
        return 100;
    }
}

/**
 * 独立对象:视频文件类
 */
class VideoFile extends Filesystem
{
    public function getName()
    {
        return '视频:'. $this->name;
    }

    public function getSize()
    {
        return 200;
    }
}

组合模式中,组合对象必须在合适的地方提供独立对象的管理方法,如:add()remove()等。

组合模式分为安全模式透明模式,这是根据接口中是否包含管理对象的方法来区分的。

上面的例子我们举例的是安全模式,在接口中没有声明add()remove()方法管理方法。

这样有一个缺点:组合对象和独立对象不具有相同的接口,客户端调用需要做相应的判断,带来了不便。

另外一种是透明模式,在接口中就声明add()remove()方法。

这样所有的实现类都具备了add()remove(),好处就是组合对象和独立对象具有一致的接口。

但问题也很明显,因为独立对象不具备add()remove()方法的功能,所以实现他是没有意义的。

不管那种模式,都根据实际需要来配置。

2.4 客户端

然后,我们就可以在客户端中使用这个程序。

例如,我们要构建这样一个文件目录结构:

home
├─text1.txt
├─bg1.png
├─film1.mp4
├─source
│  ├─text2.txt

代码就是:

// 创建home目录,并加入三个文件
$dir = new Dir('home');
$dir->add(new TextFile('text1.txt'));
$dir->add(new ImageFile('bg1.png'));
$dir->add(new VideoFile('film1.mp4'));

// 在home下创建子目录source
$subDir = new Dir('source');
$dir->add($subDir);

// 创建一个text2.txt,并放到子目录source中
$text2 = new TextFile('text2.txt');
$subDir->add($text2);

// 打印信息
echo $text2->getName(), '-->', $text2->getSize();
echo '<br />';
echo $subDir->getName(), ' --> ',$subDir->getSize();
echo '<br />';
echo $dir->getName(), ' --> ', $dir->getSize();

可以看到,文件对象(独立对象)获取名称用getName()方法,目录对象(组合对象)用的也是getName()方法。

同样,获取大小用的也都是getSize()方法。

输出的结果为:

文本文件:text2.txt-->10
目录:source --> 10
目录:home --> 320

3 特点

在组合模式中,组合对象和独立对象必须实现一个接口

其中,组合对象必须包含添加和删除节点对象

组合模式通过和装饰模式有着类似的结构图,但是组合模式旨在构造类,而装饰模式重在不生成子类即可给对象添加职责。

并且,装饰模式重在修饰,而组合模式重在表示

组合模式的UML图:

7

设计模式-适配器模式

适配器模式,即根据客户端需要,将某个类的接口转换成特定样式的接口,以解决类之间的兼容问题。

如果我们的代码依赖一些外部的API,或者依赖一些可能会经常更改的类,那么应该考虑用适配器模式。

下面我们以集成支付宝支付功能为例。

1 问题

假设支付宝支付类的功能如下:

/**
 * 支付宝支付类
 */
class Alipay
{
    public function sendPayment()
    {
        echo '使用支付宝支付。';
    }
}

// 客户端代码
$alipay = new Alipay();
$alipay->sendPayment();

我们直接实例化Alipay类完成支付功能,这样的客户端代码可能很多。

一段时间后,如果支付宝的Alipay类升级,方法名由sendPayment()变成goPayment()会怎样?

所有用了sendPayment()的客户端代码都要改变。

如果Alipay类频繁升级,或者客户端在很多地方使用,这会是极大的工作量。

2 解决

现在我们用适配器模式来解决。

我们在客户端和Alipay类之间加一个中间类,也就是适配器类,转换原始的Alipay为客户端需要的形式。

为让客户端能调用到统一的类方法,我们先定义一个适配器接口:

/**
 * 适配器接口,所有的支付适配器都需实现这个接口。
 * 不管第三方支付实现方式如何,对于客户端来说,都
 * 用pay()方法完成支付
 */
interface PayAdapter
{
    public function pay();
}

因为Alipay类我们无法控制,而且它有可能经常更新,所以我们不对它做任何修改。

我们新建一个AlipayAdapter适配器类,在pay()中转换Alipay的支付功能,如下:

/**
 * 支付宝适配器
 */
class AlipayAdapter implements PayAdapter
{
    public function pay()
    {
        // 实例化Alipay类,并用Alipay的方法实现支付
        $alipay = new Alipay();
        $alipay->sendPayment();
    }
}

客户端使用方式:

// 客户端代码
$alipay = new AlipayAdapter();
// 用pay()方法实现支付
$alipay->pay();

这样,当Alipay的支付方法改变,只需要修改AlipayAdapter类就可以了。

3 适配新类

有了适配器后,扩展也变得更容易了。

继续以上的例子,在支付宝的基础上,我们再增加微信支付,它与支付宝的支付方式不同,必须通过扫码才能支付。

这种情况也应该使用适配器,而不是直接使用微信的支付功能。

代码如下:

/**
 * 微信支付类
 */
class WechatPay
{
    public function scan()
    {
        echo '扫描二维码后,';
    }

    public function doPay()
    {
        echo '使用微信支付';
    }
}

/**
 * 微信支付适配器
 */
class WechatPayAdapter implements PayAdapter
{
    public function pay()
    {
        // 实例化WechatPay类,并用WechatPay的方法实现支付。
        // 注意,微信支付的方式和支付宝的支付方式不一样,但是
        // 适配之后,他们都能用pay()来实现支付功能。
        $wechatPay = new WechatPay();
        $wechatPay->scan();
        $wechatPay->doPay();
    }
}

客户端使用:

// 客户端代码
$wechat = new WechatPayAdapter();
// 也是用pay()方法实现支付
$wechat->pay();

这就是适配器的扩展特性。

我们创建了一个用于处理第三方类(支付宝、微信支付)的方法,

如果它们的API有变化,我们仅需修改客户端依赖的适配器类就可以,不用修改、暴露第三方类本身。

4 UML图

以上适配器模式的代码对应UML如下:

6

注意:适配器模式中,适配器类的名称和创建方式一定是不会频繁改动的。

对于客户端来说,引用适配器类的方式应该是统一而不变的,这才算是正确使用适配器。

5 总结

大的应用都会不断地加入新库和新API。

为避免它们的变更引发问题,应该用适配器模式包装起来,提供应用统一的引用方式。

它会让我们的代码更具结构化,便于管理和扩展。

创建型模式:工厂方法模式

1.定义:

工厂方法模式(Factory Method Pattern)又称为工厂模式,也叫虚拟构造器(Virtual Constructor)模式或者多态工厂(Polymorphic Factory)模式,它属于类创建型模式。在工厂方法模式中,工厂父类负责定义创建产品对象的公共接口,而工厂子类则负责生成具体的产品对象,这样做的目的是将产品类的实例化操作延迟到工厂子类中完成,即通过工厂子类来确定究竟应该实例化哪一个具体产品类。
在工厂方法模式中,我们不再提供一个统一的工厂类来创建所有的产品对象,而是针对不同的产品提供不同的工厂,系统提供一个与产品等级结构对应的工厂等级结构。

2.工厂方法模式的意图?

在简单工厂模式中,所有的产品都由同一个工厂创建,工厂类职责较重,业务逻辑较为复杂,具体产品与工厂类之间的耦合度高,严重影响了系统的灵活性和扩展性,而工厂方法模式则可以很好地解决这一问题。

3.工厂方法模式解决一个什么问题?

弥补简单工厂模式的不足,增强系统的灵活性与扩展性。

4.工厂方法模式的应用场景:

(1)一个类不知道它所需要的对象的类:在工厂方法模式中,客户端不需要知道具体产品类的类名,只需要知道所对应的工厂即可,具体的产品对象由具体工厂类创建;客户端需要知道创建具体产品的工厂类。

(2)一个类通过其子类来指定创建哪个对象:在工厂方法模式中,对于抽象工厂类只需要提供一个创建产品的接口,而由其子类来确定具体要创建的对象,利用面向对象的多态性和里氏代换原则,在程序运行时,子类对象将覆盖父类对象,从而使得系统更容易扩展。

(3)将创建对象的任务委托给多个工厂子类中的某一个,客户端在使用时可以无须关心是哪一个工厂子类创建产品子类,需要时再动态指定,可将具体工厂类的类名存储在配置文件或数据库中。

5.工厂方法模式是如何解决3中的问题的?

在工厂方法模式中,我们不再提供一个统一的工厂类来创建所有的产品对象,而是针对不同的产品提供不同的工厂,系统提供一个与产品等级结构对应的工厂等级结构。

6.工厂方法模式的结构图及关键代码

图2 工厂方法模式结构图

时序图

../_images/seq_FactoryMethod.jpg

       在工厂方法模式结构图中包含如下几个角色:

    ● Product(抽象产品):它是定义产品的接口,是工厂方法模式所创建对象的超类型,也就是产品对象的公共父类。

  ● ConcreteProduct(具体产品):它实现了抽象产品接口,某种类型的具体产品由专门的具体工厂创建,具体工厂和具体产品之间一一对应。

   ● Factory(抽象工厂):在抽象工厂类中,声明了工厂方法(Factory Method),用于返回一个产品。抽象工厂是工厂方法模式的核心,所有创建对象的工厂类都必须实现该接口。

    ● ConcreteFactory(具体工厂):它是抽象工厂类的子类,实现了抽象工厂中定义的工厂方法,并可由客户端调用,返回一个具体产品类的实例。

关键代码:

//日志记录器接口:抽象产品
interface Logger {
 public void writeLog();
}

//数据库日志记录器:具体产品
class DatabaseLogger implements Logger {
 public void writeLog() {
 System.out.println("数据库日志记录。");
 }
}

//文件日志记录器:具体产品
class FileLogger implements Logger {
 public void writeLog() {
 System.out.println("文件日志记录。");
 }
}

//日志记录器工厂接口:抽象工厂
interface LoggerFactory {
 public Logger createLogger();
}

//数据库日志记录器工厂类:具体工厂
class DatabaseLoggerFactory implements LoggerFactory {
 public Logger createLogger() {
 //连接数据库,代码省略
 //创建数据库日志记录器对象
 Logger logger = new DatabaseLogger(); 
 //初始化数据库日志记录器,代码省略
 return logger;
 } 
}

//文件日志记录器工厂类:具体工厂
class FileLoggerFactory implements LoggerFactory {
 public Logger createLogger() {
 //创建文件日志记录器对象
 Logger logger = new FileLogger(); 
 //创建文件,代码省略
 return logger;
 } 
}

7.工厂方法模式的优缺点:

主要优点:

  1. (1)在工厂方法模式中,工厂方法用来创建客户所需要的产品,同时还向客户隐藏了哪种具体产品类将被实例化这一细节,用户只需要关心所需产品对应的工厂,无须关心创建细节,甚至无须知道具体产品类的类名。
  2. (2)基于工厂角色和产品角色的多态性设计是工厂方法模式的关键。它能够使工厂可以自主确定创建何种产品对象,而如何创建这个对象的细节则完全封装在具体工厂内部。工厂方法模式之所以又被称为多态工厂模式,是因为所有的具体工厂类都具有同一抽象父类。
  3. (3)使用工厂方法模式的另一个优点是在系统中加入新产品时,无须修改抽象工厂和抽象产品提供的接口,无须修改客户端,也无须修改其他的具体工厂和具体产品,而只要添加一个具体工厂和具体产品就可以了。这样,系统的可扩展性也就变得非常好,完全符合“开闭原则”。

主要缺点:

(1)在添加新产品时,需要编写新的具体产品类,而且还要提供与之对应的具体工厂类,系统中类的个数将成对增加,在一定程度上增加了系统的复杂度,有更多的类需要编译和运行,会给系统带来一些额外的开销。
(2)由于考虑到系统的可扩展性,需要引入抽象层,在客户端代码中均使用抽象层进行定义,增加了系统的抽象性和理解难度,且在实现时可能需要用到DOM、反射等技术,增加了系统的实现难度。

8.工厂方法模式的应用实例:

(1)Sunny公司开发人员决定使用工厂方法模式来设计日志记录器;

(2)造汽车的工厂只造汽车,造火车的只造火车,不管造汽车还是火车但造出来的还是车。

 

创建型模式:简单工厂模式

1.定义:

简单工厂模式(Simple Factory Pattern):又称为静态工厂方法(Static Factory Method)模式,它属于类创建型模式。在简单工厂模式中,可以根据参数的不同返回不同类的实例。简单工厂模式专门定义一个类来负责创建其他类的实例,被创建的实例通常都具有共同的父类。

2.简单工厂模式的意图?

意图在于当你需要什么,只需要传入一个正确的参数,就可以获取你所需要的对象,而无须知道其创建细节。

3.简单工厂模式解决一个什么问题?

把对象的创建集中在一个地方(工厂中),在增加新的对象类型的时候,只需要改变工厂方法即可;否则在应用中四处散布对象创建逻辑,如果创建方法改变时则需要四处修改,增加维护的成本。

4.简单工厂模式应用场景:

* 工厂类负责创建的对象比较少:由于创建的对象较少,不会造成工厂方法中的业务逻辑太过复杂。

* 客户端只知道传入工厂类的参数,对于如何创建对象不关心:客户端既不需要关心创建细节,甚至连类名都不需要记住,只需要知道类型所对应的参数。

5.简单工厂模式是如何解决3中的问题的?

把对象的创建集中在一个地方(工厂中),在增加新的对象类型的时候,只需要改变工厂方法即可。

6.简单工厂模式的结构图及关键代码:

简单工厂模式包含如下角色:
  • Factory:工厂角色
    工厂角色负责实现创建所有实例的内部逻辑
  • Product:抽象产品角色
    抽象产品角色是所创建的所有对象的父类,负责描述所有实例所共有的公共接口
  • ConcreteProduct:具体产品角色
    具体产品角色是创建目标,所有创建的对象都充当这个角色的某个具体类的实例。
../_images/SimpleFactory.jpg

时序图

../_images/seq_SimpleFactory.jpg

代码分析
#include "Factory.h"
#include "ConcreteProductA.h"
#include "ConcreteProductB.h"
Product* Factory::createProduct(string proname){
 if ( "A" == proname )
 {
 return new ConcreteProductA();
 }
 else if("B" == proname)
 {
 return new ConcreteProductB();
 }
 return NULL;
}

7.简单工厂模式的优缺点:

主要优点:

  • (1)工厂类含有必要的判断逻辑,可以决定在什么时候创建哪一个产品类的实例,客户端可以免除直接创建产品对象的责任,而仅仅“消费”产品;简单工厂模式通过这种做法实现了对责任的分割,它提供了专门的工厂类用于创建对象。
  • (2)客户端无须知道所创建的具体产品类的类名,只需要知道具体产品类所对应的参数即可,对于一些复杂的类名,通过简单工厂模式可以减少使用者的记忆量。
  • (3)通过引入配置文件,可以在不修改任何客户端代码的情况下更换和增加新的具体产品类,在一定程度上提高了系统的灵活性。

主要缺点:

  • (1)由于工厂类集中了所有产品创建逻辑,一旦不能正常工作,整个系统都要受到影响。
  • (2)使用简单工厂模式将会增加系统中类的个数,在一定程序上增加了系统的复杂度和理解难度。
  • (3)系统扩展困难,一旦添加新产品就不得不修改工厂逻辑,在产品类型较多时,有可能造成工厂逻辑过于复杂,不利于系统的扩展和维护。
  • (4)简单工厂模式由于使用了静态工厂方法,造成工厂角色无法形成基于继承的等级结构。

8.简单工厂模式的应用实例:

(1)一个简单的软件应用场景,一个软件系统可以提供多个外观不同的按钮(如圆形按钮、矩形按钮、菱形按钮等), 这些按钮都源自同一个基类,不过在继承基类后不同的子类修改了部分属性从而使得它们可以呈现不同的外观,如果我们希望在使用这些按钮时,不需要知道这些具体按钮类的名字,只需要知道表示该按钮类的一个参数,并提供一个调用方便的方法,把该参数传入方法即可返回一个相应的按钮对象。
(2)一个生活的应用实例:某电视生产厂,生产不同品牌的电视机,当生产海尔电视时,只需在调用该工厂的工厂方法时,传入“Haier”即可;当生产创维电视时,传入“Chuangwei”即可。

 

设计模式学习资料

1.总结比较全的:http://blog.csdn.net/lovelion/article/details/17517213

2.图说设计模式:http://design-patterns.readthedocs.io/zh_CN/latest/creational_patterns/creational.html

详细说明:https://github.com/me115/design_patterns

3.设计模式笔记:http://www.runoob.com/design-pattern/design-pattern-tutorial.html

4.PHP版设计模式:https://www.awaimai.com/patterns