IT铁人DAY 14－Decorator 装饰者模式

　　今天要介绍的Decorator Pattern，跟昨天的Composite Pattern都是属於Structural Pattern，你可能会发现它们的Class Diagram有点雷同，现在就来认识一下吧！

问题情境与解析

　　现在想像一下，你正在开发一个通知的功能，初始的版本非常简单，就一个Constructor和一个简单的送出方法，随着时间慢慢发展，你的通知功能也许不只是用简讯通知，可能会用电子邮件或是其他第三方软件通知，尽可能满足用户的需求。

　　後来又有个需求，想要一次不只用一种方式通知，也许是用简讯加电子邮件，或是用电子邮件加第三方软件通知，还有可能是一次使用三种不同方式去通知用户，然而你会为了种种的特殊需求去建立新的子类别来解决问题，但一次一次的增加，便会造成程序码快速的成长，你需要的是一种方法可以建构这种通知类别的结构，使程序码膨胀的速度趋缓。

　　Decorator能够允许在不用改变结构的情况下，对现有的物件添加新的功能，这个模式会创建一个装饰类别，它将会保持现有类别的结构并增添新的附加功能。

　　也就是说，我们能够用最简单的简讯通知作为基本功能，其他的电子邮件或是第三方软件的通知一并做成装饰者，如果想要有不同组合的通知，只要使用装饰者就可以将简讯通知的功能额外再添加另一种通知方式罗！

Class Diagram

Skeleton Code

interface Component {
    public void execute();
}

class ConcreteComponent implements Component {
    private Type field;
	
    public ConcreteComponent(Type field) {
        this.field = field;
    }

    public void execute() {
        // Do some work
    }
}

abstract class AbstractDecorator implements Component {
    private Component wrap;

    public AbstractDecorator(Component c) {
        this.wrap = c;
    }

    public void execute() {
        wrap.execute();
    }
}

class ConcreteDecorator extends AbstractDecorator {
    private Type field;
	
    public ConcreteDecorator(Component c) {
        super(c);
    }

    public void execute() {
        wrap.execute();
        extra();
    }

    public void extra() {
        // extra behavior
    }
}

　　Concrete Decorator 和 Concrete Component 都是属於 Component 型，也就是说，不管是单纯的简讯通知，或是是电子邮件加上第三方软件通知，对用户来说都是一种通知而已，不须去耦合如此多类型的通知类别，只要将被包装的物件给包装者引用，那麽结果就会是一种不一样的组合行为。

除此之外，也欢迎大家走走逛逛关於我们团队夥伴的文章

lu23770127 - SASS 基础初学三十天

10u1 - 糟了！是世界奇观！

juck30808 - Python - 数位行销分析与 Youtube API 教学

SiQing47 - 前端？後端？你早晚都要全端的，何不从现在开始？