【设计模式-装饰器模式】设计模式学习记录

设计模式6大原则

单一职责原则

一个类或者模块只负责完成一个职责（或者功能）。
也就是说我们不要设计大而全的类,而是要设计小而精。
大和小是在类的职责范围上讲，不要直接定义一个作用全局的类，看似方便调用，却提高了耦合度，一个修改全局影响。
全和精是在功能上讲，不要在一个类中设置不必要的功能，一个类放了全部的接口，之后的维护就是看一本没有目录的书，你知道这个功能是在这实现的，但你怎么也找不到具体实现的位置。

开闭原则

对扩展开放，对修改关闭
我们的项目都是在迭代中开发的，不存在从一开始就完全不需要修改的功能，越是详细的功能设计越容易出错。我们在设计时就要考虑之后的拓展性和稳定性，增添修改一个功能时，涉及的代码越少影响越小。
这是非常难做到的，但我们学习设计模式，这个原则是帮助最大的。

里氏替换原则

子类对象能够替换程序中父类对象出现的任何地方，并且保证原来程序的逻辑行为不变及正确性不被破坏。
要理解里氏替换原则，其实就是要理解两个问题：

• 什么是替换？

替换的前提是面向对象语言所支持的多态特性，同一个行为具有多个不同表现形式或形态的能力。
例：List接口的不同实现

• 什么是与期望行为一致的替换（Robert Martin所说的“必须能够替换”）？

在不了解派生类的情况下，仅通过接口或基类的方法，即可清楚的知道方法的行为，而不管哪种派生类的实现，都与接口或基类方法的期望行为一致。

我们接口的设计就符合里氏替换原则，也是多态最直观的体现。

接口隔离原则

一个类对另一个类的依赖应该建立在最小的接口上
要为各个类建立它们需要的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。
从思路上讲，这个原则和单一职责原则是相同的，都是为了降低系统的耦合度。

依赖倒置原则

高层模块不应该依赖于底层模块，二者都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。
这两句话乍一听很反直觉，我们一般说好的基础是成功的基石，但在这却说高层不依赖底层，是不是写错了呀？而且抽象不依赖细节，我们学面向对象不都是总结相同细节点做抽象的吗？
其实这就是关注点错了，两句话最重要的是依赖于抽象，高层和底层没有直接的联系，而是由抽象层建立关系，比如抽象工厂模式。
第二句同样如此，这里的细节是指实现细节，依赖实现就像是代码调用的是一个类而不是接口，代码耦合度高。
还不理解就想像自己开发了一个类似List接口，但它却是个类，其他像ArrayList是你利用这个类做的重写。这样应该能理解了吧。

迪米特法则（最少知识原则）

不该有直接依赖关系的类之间，不要有依赖；
有依赖关系的类之间，尽量只依赖必要的接口。
如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。

什么是装饰器模式

课上的例子是蛋糕，我觉得装饰器是裱花袋，它其实就是给类增加一些方法的实现。
在学的时候我一直在想，为什么不用子类，继承原有类不也可以定义新方法吗？
后来我想到IO那一套类，比如说现在要你开发一套IO，有个顶层抽象类做方法规范，有两个子类做不同的IO实现，现在要给这两个子类都实现一套加密方法，根据开闭原则，这个实现不能在原有类上添加。用子类去做，就会诞生两个新的子类，如果这套加密还需要继承别的类时就会很被动。此时装饰器模式就可以解决。

装饰器模式的角色和类图

装饰（Decorator）模式中的角色：

• 抽象构件（Component）角色 ：它是具体构件和抽象装饰类的共同父类,声明了在具体构件中实现的业务方法.它引进了可以使客户端以一致的方式处理未被装饰的对象以及装饰之后的对象,实现客户端的透明操作
• 具体构件（Concrete Component）角色 ：它是抽象构件类的子类,用于定义具体的构建对象,实现了在抽象构建中声明的方法,装饰类可以给它增加额外的职责(方法).
• 抽象装饰（Decorator）角色 ：它也是抽象构件类的子类,用于给具体构件增加职责,但是具体职责在其子类中实现.它维护了一个指向抽象构件对象的引用,通过该引用可以调用装饰之前构件对象的方法,并通过其子类扩展该方法,以达到装饰的目的.
• 具体装饰（ConcreteDecorator）角色 : 它是抽象装饰类的子类,负责向构件添加新的职责.每一个具体装饰类都定义了一些新的行为,它可以调用在抽象装饰类中定义的方法,并可以增加新的方法用于扩充对象的行为.

/**
 * 抽象构件类
 * @author spikeCong
 * @date 2022/9/27
 **/
public abstract class Component {

    //抽象方法
    public abstract void operation();
}

/**
 * 具体构建类
 * @author spikeCong
 * @date 2022/9/27
 **/
public class ConcreteComponent extends Component {

    @Override
    public void operation() {
        //基础功能实现(复杂功能通过装饰类进行扩展)
    }
}
/**
 * 抽象装饰类-装饰者模式的核心
 * @author spikeCong
 * @date 2022/9/27
 **/
public class Decorator extends Component{

    //维持一个对抽象构件对象的引用
    private Component component;

    //注入一个抽象构件类型的对象
    public Decorator(Component component) {
        this.component = component;
    }


    @Override
    public void operation() {
        //调用原有业务方法(这里并没有真正实施装饰,而是提供了一个统一的接口,将装饰过程交给子类完成)
        component.operation();
    }
}


/**
 * 具体装饰类
 * @author spikeCong
 * @date 2022/9/27
 **/
public class ConcreteDecorator extends Decorator {


    public ConcreteDecorator(Component component) {
        super(component);
    }

    @Override
    public void operation() {
        super.operation(); //调用原有业务方法
        addedBehavior(); //调用新增业务方法
    }

    //新增业务方法
    public void addedBehavior(){
        //......
    }
}

现在我们回到最开始的问题，用装饰器模式实现一套自己的IO，此时我们的加密已经不再针对具体的方法，而是抽象层的方法，不管之后它还会有怎样的子类，我们都能加密，同时我们可以有不同的方法，比如抓取关键信息、打水印…
此时，被修饰的抽象类不是我们关注的对象，不同的方法新增才是装饰器的优势。

装饰器模式的优缺点

装饰器模式的优点:

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

装饰器模式的缺点:

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