设计模式-组合模式

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

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

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

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

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

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。

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

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