结构型模式-装饰模式(扩展系统功能)

目录

• 1. 定义
• 2. 结构
• 3. 代码实现
• 4. 透明装饰模式与半透明装饰模式
  • 4.1 透明装饰模式
  • 4.2 半透明装饰模式
• 5. 注意事项
• 6. 优缺点
• 7. 适用场景
• 8. 我的理解
• 参考

装饰模式能够在不改变一个对象自己功能的基础上给对象增长额外的新行为。

装饰模式是一种用于替代继承的技术，它经过一种无须定义子类的方式来给对象动态增长职责，使用对象之间的关联关系取代类之间的继承关系。在装饰模式中引入了装饰类，在装饰类中既能够调用待装饰的原有类的方法，还能够增长新的方法，以扩充原有类的功能。

1. 定义

装饰模式(Decorator Pattern)：动态地给一个对象增长一些额外的职责，就增长对象功能来讲，装饰模式比生成子类实现更为灵活。装饰模式是一种对象结构型模式。

2. 结构

在装饰模式中，为了让系统具备更好的灵活性和可扩展性，咱们一般会定义一个抽象装饰类，而将具体的装饰类做为它的子类，装饰模式结构如图所示：

• Component（抽象构件）：它是具体构件和抽象装饰类的共同父类，声明了在具体构件中实现的业务方法，它的引入可使客户端以一致的方式处理未被装饰的对象以及装饰以后的对象，实现客户端的透明操做。
• ConcreteComponent（具体构件）：它是抽象构件类的子类，用于定义具体的构件对象，实现了在抽象构件中声明的方法，装饰器能够给它增长额外的职责（方法）。
• Decorator（抽象装饰类）：它也是抽象构件类的子类，用于给具体构件增长职责，可是具体职责在其子类中实现。它维护一个指向抽象构件对象的引用，经过该引用能够调用装饰以前构件对象的方法，并经过其子类扩展该方法，以达到装饰的目的。
• ConcreteDecorator（具体装饰类）：它是抽象装饰类的子类，负责向构件添加新的职责。每个具体装饰类都定义了一些新的行为，它能够调用在抽象装饰类中定义的方法，并能够增长新的方法用以扩充对象的行为。
• 因为具体构件类和装饰类都实现了相同的抽象构件接口，所以装饰模式以对客户透明的方式动态地给一个对象附加上更多的责任，换言之，客户端并不会以为对象在装饰前和装饰后有什么不一样。装饰模式能够在不须要创造更多子类的状况下，将对象的功能加以扩展。

3. 代码实现

原本Car只有驾驶功能，为了动态地给Car加一些其余的功能，好比加上一个电视，或者放几瓶水，使用装饰模式实现以下：

抽象构件类Icar

public interface ICar {
        void drive();
}

具体构建类1

public class Jeep implements ICar {

    @Override
    public void drive() {
        System.out.println("驾驶吉普车啦");
    }
}

具体构建类2

public class Lorry implements ICar {

    @Override
    public void drive() {
        System.out.println("开货车啦");
    }
}

抽象装饰类

public abstract class CarDecorator implements ICar {

    private ICar car;

    public CarDecorator(ICar car) {
        this.car = car;
    }

    @Override
    public void drive() {
        car.drive();
    }
}

具体装饰类1

public class TvCarDecorator extends CarDecorator {

    public TvCarDecorator(ICar car) {
        super(car);
    }

    @Override
    public void drive() {
        addTv();
        super.drive();
    }

    public void addTv(){
        System.out.println("为这部车安装了电视咯");
    }
}

具体装饰类2

public class WaterCarDecorator extends CarDecorator {

    public WaterCarDecorator(ICar car) {
        super(car);
    }

    @Override
    public void drive() {
        addWater();
        super.drive();
    }

    public void addWater(){
        System.out.println("为车子放了几瓶水");
    }
}

客户端

public class Client {

    public static void main(String[] args) {
        ICar jeepCar,lorryCar,tvCar,waterCar1,waterCar2;
        jeepCar=new Jeep();
        lorryCar=new Lorry();
        tvCar=new TvCarDecorator(jeepCar);
        waterCar1=new WaterCarDecorator(tvCar);
        waterCar1.drive();
        System.out.println("------------");
        waterCar2=new WaterCarDecorator(lorryCar);
        waterCar2.drive();
    }
}

//为车子放了几瓶水
//为这部车安装了电视咯
//驾驶吉普车啦
//------------
//为车子放了几瓶水
//开货车啦

能够将装饰了一次以后的tvCar对象注入另外一个装饰类WaterCarDecorator中实现第二次装饰，获得一个通过两次装饰的对象waterCar1，再调用waterCar1的drive()方法便可获得一个既有电视机又有放了水的吉普车。

4. 透明装饰模式与半透明装饰模式

4.1 透明装饰模式

在透明装饰模式中，要求客户端彻底针对抽象编程，装饰模式的透明性要求客户端程序不该该将对象声明为具体构件类型或具体装饰类型，而应该所有声明为抽象构件类型。对于客户端而言，具体构件对象和具体装饰对象没有任何区别。

没法单独调用新增的行为，好比

tvCar.addTv();

透明装饰模式可让客户端透明地使用装饰以前的对象和装饰以后的对象，无须关心它们的区别，此外，还能够对一个已装饰过的对象进行屡次装饰，获得更为复杂、功能更为强大的对象。在实现透明装饰模式时，要求具体装饰类的operation()方法覆盖抽象装饰类的operation()方法，除了调用原有对象的operation()外还须要调用新增的addedBehavior()方法来增长新行为。

4.2 半透明装饰模式

为了可以调用到新增方法，咱们不得不用具体装饰类型来定义装饰以后的对象，而具体构件类型仍是可使用抽象构件类型来定义，这种装饰模式即为半透明装饰模式，也就是说，对于客户端而言，具体构件类型无须关心，是透明的；可是具体装饰类型必须指定，这是不透明的。

ICar jeepCar=new Jeep();
TvCarDecorator tvCar=new TvCarDecorator(jeepCar);
tvCar.addTv();

半透明装饰模式能够给系统带来更多的灵活性，设计相对简单，使用起来也很是方便；可是其最大的缺点在于不能实现对同一个对象的屡次装饰(由于该对象新增的方法后面加入装饰类的时候仍是没法调用，因此是不完全的装饰)，并且客户端须要有区别地对待装饰以前的对象和装饰以后的对象。

5. 注意事项

1. 尽可能保持装饰类的接口与被装饰类的接口相同，这样，对于客户端而言，不管是装饰以前的对象仍是装饰以后的对象均可以一致对待。这也就是说，在可能的状况下，咱们应该尽可能使用透明装饰模式。
2. 尽可能保持具体构件类ConcreteComponent是一个“轻”类，也就是说不要把太多的行为放在具体构件类中，咱们能够经过装饰类对其进行扩展。
3. 若是只有一个具体构件类，那么抽象装饰类能够做为该具体构件类的直接子类。（不须要定义抽象构建了，可是之后无法扩展新的具体构建类）

6. 优缺点

• 优势

1. 对于扩展一个对象的功能，装饰模式比继承更加灵活性，不会致使类的个数急剧增长。
2. 能够经过一种动态的方式来扩展一个对象的功能，经过配置文件能够在运行时选择不一样的具体装饰类，从而实现不一样的行为。
3. 能够对一个对象进行屡次装饰，经过使用不一样的具体装饰类以及这些装饰类的排列组合，能够创造出不少不一样行为的组合，获得功能更为强大的对象。
4. 具体构件类与具体装饰类能够独立变化，用户能够根据须要增长新的具体构件类和具体装饰类，原有类库代码无须改变，符合“开闭原则”。

• 缺点

1. 使用装饰模式进行系统设计时将产生不少小对象，这些对象的区别在于它们之间相互链接的方式有所不一样，而不是它们的类或者属性值有所不一样，大量小对象的产生势必会占用更多的系统资源，在必定程序上影响程序的性能。
2. 装饰模式提供了一种比继承更加灵活机动的解决方案，但同时也意味着比继承更加易于出错，排错也很困难，对于屡次装饰的对象，调试时寻找错误可能须要逐级排查，较为繁琐。

7. 适用场景

1. 在不影响其余对象的状况下，以动态、透明的方式给单个对象添加职责。
2. 当不能采用继承的方式对系统进行扩展或者采用继承不利于系统扩展和维护时可使用装饰模式。不能采用继承的状况主要有两类：第一类是系统中存在大量独立的扩展，为支持每一种扩展或者扩展之间的组合将产生大量的子类，使得子类数目呈爆炸性增加；第二类是由于类已定义为不能被继承（如Java语言中的final类）。

8. 我的理解

装饰模式下降了系统的耦合度，能够动态增长或删除对象的职责，并使得须要装饰的具体构件类和具体装饰类能够独立变化，以便增长新的具体构件类和具体装饰类。在JavaIO中的输入流和输出流的设计、javax.swing包中一些图形界面构件功能的加强,多重加密的设计能够运用装饰模式。

参考

1. Java设计模式-刘伟