经常使用设计模式：装饰者模式

　　今天看了一篇很棒的介绍装饰者模式的文章，因而就按照以往的惯例，学习了以后手动的码了这么一篇随记记录本身的体会，而且参考原文的例子，本身手动的实现了一遍整个demo，原文地址为：http://blog.csdn.net/zhaoyanjun6/article/details/56488020

　　首先咱们来大致了解一下装饰者模式到底是个什么东西呢？所谓的装饰者，能够参考如今很火的一个游戏——绝地大逃杀里头的枪械自由改装的概念来解释装饰者模式的概念。如今有这么一把AK47枪，除了枪以外，没有任何之外的配件，看到人就只能拿着把裸的AK随便的突突突，碰运气看看能不能打中人。而忽然该玩家得到了一个八倍瞄准镜，和一个消声器，这时候该玩家就能够把这个瞄准镜和消声器安装到AK上，而后他就能够用这把AK的八倍镜去瞄准2000米外的敌人，而后用AK上的消声器，悄无声息的击杀别人。而这时候，这个玩家用腻了AK，因而又把这个瞄准镜和消声器安装到了本身的沙漠飞鹰的手枪上，这时候，这个沙漠飞鹰就具备了和AK的同样的功能。这个就是咱们所谓的装饰者模式，经过装饰器装饰以后，咱们的目标就会具备一个新的功能。

　　那么了解了装饰者模式是什么以后，它的好处就更一目了然了吧？在拓展一个类的功能的时候，一般可使用继承来实现功能的拓展,若是这些须要拓展的功能的种类很繁多,那么势必生成不少子类,增长系统的复杂性,同时,使用继承实现功能拓展,咱们必须可预见这些拓展功能,这些功能是编译时就肯定了,是静态的。而经过装饰者模式来作这个事情，就能够完美的解决这些问题。就用咱们刚刚那个例子来讲，若是经过继承来实现的话，那么势必AK47下会有这么些子类，带瞄准镜的AK，带消声器的AK，带瞄准镜和消声器的AK，这就很蛋疼咯吧？并且若是要用在沙漠飞鹰之上，又要有带瞄准镜的沙漠飞鹰子类等，会有无数的子类出现。

　　二话不说 ，那么接下来咱们先来看看代码

先看看被装饰者的代码：

public interface Gun {

    void status();
    
}

public class AK47 implements Gun {

    @Override
    public void status() 
    {
        System.out.println("当前AK没有任何配件");
        
    }
}

public class DesertEagle implements Gun {

    @Override
    public void status() 
    {
        System.out.println("当前沙漠飞鹰没有任何配件");
        
    }
}

被装饰者都共同实现了一个叫GUN的接口（AK和沙漠飞鹰都属于枪，在这个接口下有一个方法叫status表示当前该枪具备什么配件），接下来看看咱们的装饰器类：

public abstract class GunPart implements Gun {

    Gun gun;
    
    public GunPart(Gun gun) 
    {
        this.gun=gun;
    }
    
    @Override
    public void status() {
        gun.status();
    }
}


public class muffler extends GunPart {

    public muffler(Gun gun) {
        super(gun);
    }

    @Override
    public void status() {
        super.status();
        say();
    }

    public void say()
    {
        System.out.println("该枪有了消声器");
    }
}

public class telescope extends GunPart {

    
    public telescope(Gun gun) {
        super(gun);
        // TODO Auto-generated constructor stub
    }

    @Override
    public void status() {
        // TODO Auto-generated method stub
        super.status();
        say();
    }
    
    public void say()
    {
        System.out.println("该枪有了瞄准镜");
    }

}

在装饰器当中，咱们抽象了这么一个抽象类叫作GunPart，而不管是消声器仍是瞄准镜都是属于GunPart（枪械配件的一部分）因此都是继承了这个GunPart，而这个GunPart同时也实现了Gun这个接口，注意这里是重点，这个GunPart必定也要实现这个Gun接口，不然就没法实现装饰器可叠加的效果了。而继承了GunPart的子类，都会重写父类的status方法，重写的内容第一行必定是调用父类的.status方法。而后再加上该子类添加的特点功能，在例子中是say()方法。

接下来看看咱们的测试代码和测试结果：

public class test {

    public static void main(String[] args) {
        // TODO Auto-generated method stub
        Gun AK47=new AK47();
        muffler muffler=new muffler(AK47);
        telescope telescope=new telescope(muffler);
        telescope.status();
        
        System.out.println();
        
        Gun DS=new DesertEagle();
        muffler muffler1=new muffler(DS);
        telescope telescope1=new telescope(muffler1);
        telescope1.status();
    }

}

当前AK没有任何配件
该枪有了消声器
该枪有了瞄准镜

当前沙漠飞鹰没有任何配件
该枪有了消声器
该枪有了瞄准镜

这样，咱们一个完整的装饰者模式的demo就写完了，那么咱们来试着总结一下装饰者模式的一些重点，首先看看这个继承和实现关系图：

• Component抽象构件角色：真实对象和装饰对象有相同的接口。这样，客户端对象就可以以与真实对象相同的方式同装饰对象交互。用咱们例子里的话，就是Gun这个接口。
• ConcreteCompoent 具体构建角色(真实对象)：定义一个将要接收附加责任的类。用咱们例子里的话，就是AK47这个类和沙漠飞鹰这个类。
• Decorator装饰角色：持有一个抽象构件的引用。装饰对象接受全部客户端的请求，并把这些请求转发给真实的对象。这样，就能在真实对象调用先后增长新的功能。例子里对应的是GunPart这个抽象类。
• ConcreteDecorate具体装饰角色：负责给构件对象增长新的功能。对应的就是消声器和八倍镜那个类了。

总的来讲，装饰模式下降系统的耦合度，能够动态的增长或删除对象的责任（在写test类的方法的时候，动态的添加或者不添加），并使得须要装饰的具体构建类和具体装饰类能够独立变化，以便增长新的具体构建类和具体装饰类。

优势

•  扩展对象功能，比继承灵活，不会致使类个数急剧增长。
• 能够对一个对象进行屡次装饰，创造出不一样行为的组合，获得功能更增强大的对象。
• 具体构 件 类和具体装饰类能够独立变化，用户能够根据须要本身增长新的 具体构件子类和具体装饰子类。

缺点

• 产生不少小对象。大量小的对象占据内存，必定程度上影响性能。
• 装饰模式易出错，调试排查比较麻烦。

那么装饰者模式讲到这里，就差很少。。。。。。。。。。。。。。。壳斗麻袋~！！！！你看到这里确定会忽然发觉，诶？这个装饰者模式怎么特么的和静态代理那么像啊？

1.一样都是加强类（装饰器）和目标类（被装饰者）实现了同一个接口。

2.一样都是经过加强类（装饰器）重写和目标类（被装饰者）来加强方法。

 

这特么不是同样的嘛？

其实我看到这里的时候，也产生了这么一个疑问，因而就去查阅了其余关于代理模式和装饰者模式，因而获得了如下三点：

1.装饰器模式关注于在一个对象上动态的添加方法，然而代理模式关注于控制对对象的访问。

2.装饰器模式能够叠加的为被装饰者装饰，而代理不支持多层嵌套。这也是我为何在前边“划重点”的缘由。

好啦，具体的仍是本身体会吧。（其实本身这一块也还不大会，一块儿学习咯）