Day22 设计模式之装饰模式

设计模式及其作用

设计模式概念

• 一套被多数人知晓、经过分类编目的、反复使用的优秀代码设计经验的总结。 特定环境下特定问题的处理方法。

设计模式的作用

• 重用设计和代码
  
  • 重用设计比重用代码更有意义，自动带来代码重用
• 提高扩展性
  
  • 大量使用面向接口编程，预留扩展插槽，新的功能或特性很容易加入到系统中来
• 提高灵活性
  
  • 通过组合提高灵活性，可以允许代码修改平稳发生，对一处的修改不会波及到很多其他模块；
• 提高开发效率
  
  • 正确使用设计模式，可以节省大量的时间

设计模式的分类

分类1

面向对象设计原则

面向对象设计的基石
面向对象设计质量的依据和保障
设计模式是面向对象设计原则的经典应用

创建型设计模式

解决类的实例化问题，提高创建对象效率

结构型设计模式

解决类或对象的组成结构问题，

行为型设计模式

解决类或对象之间的交互问题、职责分配问题

分类2

类设计模式

• 用于处理类和子类之间的关系。
• 通过继承建立关系，是静态的，在编译时就已经确定。
• 因为从某种意义上说，几乎所有模式都是使用继承机制，因此此处的“类模式”是指集中处理类间关系的模式，只有很少部分模式属于此类。

对象设计模式

• 用于处理对象间的关系。
• 这些关系具有动态性，在运行期间是可以变化的。

面向对象设计原则

1、单一职责原则SRP

1、概念

单一职责原则 SRP — Single Responsibility Principle

There should never be more than one reason for a class to change。

应该有且仅有一个原因引起类的变更

• 系统中的每一个类都应该只有一个职责，而所有类所关注的就是自身职责的完成
• 职责是指为"变化的原因"
• 如果能想到多个原因去改变一个类，这个类就具有多个职责
• 并不是单一功能原则，并不是每个类只能有一个方法，而是单一"变化的原因"原则
• 如果一个类有多个职责，这些职责就耦合在了一起，当一个职责发生变化时，可能会影响其它的职责
• 多个职责耦合在一起，会影响复用性（可能只需要复用该类某一个职责，但该职责跟其它职责耦合在一起，很难分离出来）

2、好处

• 单一职责原则的意思就是经常说的" 高内聚、低耦合"

3、举例

4、总结

• 单一职能原则是所有原则中最简单的、最难应用的一个；要注意过犹不及
• "变化的原因"，只有实际发生时才有意义。可能预测到会有多个原因引起这个类的变化，但这仅仅是预测，并没有真的发生，这个类仍可看做具有单一职责，不需要分离
• JavaEE中的分层框架模式实际上体现了单一职责原则

2、开闭原则OCP

1、概念

开闭原则OCP–Open Closed Principle

Software entities should be open for extension,but closed for modification。

软件实体应当对扩展开放，对修改关闭。更通俗翻译：软件系统中的各种组件，如模块（Modules）、类（Classes）以及功能（Functions）等，应该在不修改现有代码的基础上，引入新功能。

• 实现开闭原则的关键是抽象
• 定义一个抽象层，只规定功能而不提供实现，实现通过定义具体类来完成
• 当需求变化时，不是通过修改抽象层来完成，而是通过定义抽象层的新实现(扩展)完成
• 通过抽象类及接口，规定了具体类的特征作为抽象层，相对稳定，不需修改，从而满足"对修改关闭"；从抽象类导出的具体类可以改变系统的行为，从而满足"对扩展开放"

2、好处

• 通过扩展已有软件系统，可提供新的行为，以满足对软件的新需求，提高了软件系统的适应性和灵活性
• 已有的软件模块，特别是最重要的抽象层模块不能再修改，提高了软件系统的一定的稳定性和延续性
• 这样的设计同时也满足了可复用性与可维护性

3、举例

4、总结

• 实现开闭原则的关键是抽象
• 抽象层相对稳定，不需修改，需求变化后通过重新定义抽象层的新实现来完成
• 即使无法百分之百的做到开闭原则，但朝这个方向努力，可以显著改善一个系统的结构
• 对系统每个部分都肆意地进行抽象也不是一个好主意，应该仅仅对程序中需求频繁变化部分进行抽象。拒绝不成熟的抽象和抽象本身一样重要
• 开闭原则具有理想主义的色彩，它是面向对象设计的终极目标。其他设计原则都可以看作是开闭原则的实现手段或方法
• 软件系统的构建是一个需要不断重构的过程，100%满足开闭原则的软件系统是相当困难的，这就是开闭原则的相对性。但在设计过程中，通过对模块功能的抽象（接口定义），模块之间的关系的抽象（通过接口调用），抽象与实现的分离（面向接口的程序设计）等，可以尽量接近满足开闭原则

3、里氏替代原则LSP

1、概念

里氏替代原则LSP–Liskov Substitution Principle

functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
所有引用基类的地方必须能透明地使用其子类的对象。

通俗点讲只要父类能出现的地方子类就可以出现，而且调用子类还不产生任何的错误或异常，调用者可能根本就不需要知道是父类还是子类。但是反过来就不成了，有子类出现的地方，父类未必就能适应。

里氏替换法则包含了四层意思：

1. 子类必须完全实现父类的方法

2. 子类可以有自己的个性

3. 覆盖和实现父类的方法时，输入参数可以被放大，但不能被缩小

4. 覆盖和实现父类的方法时，输出结果可以被缩小，但不能被放大

2、好处

• 而里氏代换原则对如何良好继承提出了衡量依据

3、举例

1、正方形是长方形吗？

2、企鹅/鸵鸟是鸟吗？

3、玩具手枪是手枪吗？

建议：如果子类不能完整实现父类的方法，或者是父类的某些方法在子类中已经发生"畸变"，那么建议断开父子继承关系，采用依赖、聚集、组合等关系代替继承。

4、Q:请从里氏替换原则的角度考察java.util库中的Properties与Hashtable关系是否合适。

A：从LSP的角度来看，Properties与Hashtable的关系是不合适的。Properties是一种特殊的Hashtable，它只接受String类型的键(Key)和值(Value)。但是，其超类型则可以接受任何类型的键和值。这就意味着，在一些需要非String类型的键和值的地方，Properties不能够取代Hashtable。这是一个Java语言API本身违反LSP原则的反面教材。

4、总结

• 采用开闭原则必然用到抽象和多态，而这离不开继承。而里氏代换原则对如何良好继承提出了衡量依据。里氏代换原则是使代码符合开闭原则的一个重要保证。

4、依赖倒置原则DIP

1、概念

依赖倒置原则DIP –Dependence Inversion Principle

High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions。翻译过来，包含三层含义：高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。

抽象：即抽象类或接口，两者是不能够实例化的。

细节：即具体的实现类，实现接口或者继承抽象类的类，可通过关键字new直接被实例化。

依赖正置就是类间的依赖是实实在在的实现类间的依赖，也就是面向实现编程

依赖倒置原则的本质其实就是通过抽象（抽象类或接口）使各个类或模块的实现彼此独立，不相互影响，实现模块间的松耦合

依赖倒置有三种方式来实现

通过构造函数传递依赖对象；通过setter方法传递依赖对象；接口声明实现依赖对象

依赖倒置原则的几大规则

• 每个类尽量都有接口和抽象类，或者抽象类和接口都有。
• 变量的表面类型尽量是接口或者是抽象类。
• 任何类都不应该从具体类派生。（做二次开发时，无法获得高层代码的时候例外）
• 尽量不要覆写基类已经实现好的方法。

2、好处

• 采用依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，减少并行开发引起的风险，提高代码的可读性和可维护性。

3、举例

• 早期电脑所有硬件整合在一起，一个模块坏全部坏，现在的电脑依赖于插槽（规范），更换cpu、内存、卡等方便。

4、总结

• 依赖倒置原则核心就是要面向接口编程，理解了面向接口编程，也就理解了依赖倒置
• 如果没有实现依赖倒置原则，那么也就意味着开闭原则也无法实现。
• 结合实际情况使用此原则，要考虑生产和成本，不能生搬硬套

5、接口分离原则ISP

1、概念

接口分离原则ISP–Interface Segregation Principle

有两种定义

第一种：Clients should not be forced to depend upon interfaces that they don't use.客户端不应该强行以来它不需要的接口

第二种：The dependency of one class to another one should depend on the smallest possible interface.类间的依赖关系应该建立在最小的接口上

接口隔离原则的含义：

建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。也就是说，要为各个类建立专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。

在使用接口隔离原则的时候需要有一些规范：

1、接口尽量小.保证一个接口只服务一个子模块或者业务逻辑

2、接口高内聚。接口高内聚是对内高度依赖，对外尽可能隔离。

1. 定制服务。为调用者提供且只提供他需要的方法

4、接口设计有限度。根据业务及经验，仔细思考筹划，合理适度隔离接口

接口隔离原则和单一职能原则辨析

• 单一职责原则注重的是职责；而接口隔离原则注重对接口依赖的隔离。
• 单一职责原则主要是约束类，其次才是接口和方法，它针对的是程序中的实现和细节；而接口隔离原则主要约束接口接口，主要针对抽象，针对程序整体框架的构建。

2、好处

• 防止庞大、臃肿的接口，避免"接口污染"，提高灵活性和可维护性

3、举例

• 在车站售票窗口排队的人有买票的，有查开车信息，有退票的，不必排在同一窗口中。多开几窗口，每个窗不同功能，让不同需求的人排在不同窗口，可以节约时间和人力。

4、总结

• 注意控制接口的粒度，接口不能太小，如果太小会导致系统中接口泛滥，不利于维护；
• 接口也不能太大，太大的接口将违背接口隔离原则，灵活性较差，使用起来很不方便。
• 一般而言，接口中仅包含为某一类用户定制的方法即可，不应该强迫客户依赖于那些它们不用的方法。

6、迪米特法则LOD

1、概念

迪米特法则LOD–Law of Demeter

talk only to your immediate friends

只与你直接的朋友通信（不跟陌生人说话，朋友越少越好）

如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用.如果其中一个类需要调用另一个类的方法的话,可以通过第三者转发这个调用.

迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。

应用迪米特法则有可能造成的一个后果就是：系统中存在大量的中介类，这些类之所以存在完全是为了传递类之间的相互调用关系——这在一定程度上增加了系统的复杂度。

2、好处

• 尽量降低类与类之间的耦合

3、举例

4、总结

• 过分的使用迪米特原则，会产生大量这样的中介和传递类，导致系统复杂度变大。所以在采用迪米特法则时要反复权衡，既做到结构清晰，又要高内聚低耦合。
• 为了克服狭义迪米特法则的缺点,可以使用依赖倒转原则,引入一个抽象的类型引用"抽象陌生人"对象,使"某人"依赖于"抽象陌生人",换言之,就是将"抽象陌生人"变成朋友.
• 外观模式和中介者模式都是迪米特法则的应用

7、合成/聚合复用原则CARP

1、概念

合成/聚合复用原则CARP–Composite Aggregate Reuse Principle

Favor object composition over class inheritance.

优先使用对象组合，而不是类继承.（要尽量使用合成和聚合，尽量不要使用继承）

合成聚合复用原则是指在一个新对象中通过关联关系（组合和聚合关系）使用原来已经存在的一些对象，是之成为新对象的一部分，新的对象通过向这些原来已经具有的对象委派相应的动作或者命令达到复用已有功能的目的。

为何"要尽量使用合成和聚合，尽量不要使用继承"呢？这是因为：

1. 第一，继承复用破坏包装，它把超类的实现细节直接暴露给子类，这违背了信息隐藏的原则；
2. 第二，如果超类发生了改变，那么子类也要发生相应的改变，这就直接导致了类与类之间的高耦合，不利于类的扩展、复用、维护等，也带来了系统僵硬和脆弱的设计。
3. 第三，从超类继承而来的实现是静态的，不可能再运行时间内发生改变，因此没有足够的灵活性。

而是用合成和聚合的时候新对象和已有对象的交互往往是通过接口或者抽象类进行的，就可以很好的避免上面的不足，而且这也可以让每一个新的类专注于实现自己的任务，符合单一职责原则。

2、好处

• 非常有利于构建可维护、可复用、可扩展和灵活性好的软件系统。

3、举例

4、总结

• 组合与继承都是重要的复用方法。组合称为黑箱复用，继承称为白箱复用。
• 在OO开发的早期，继承被过度地使用
• 随着时间的发展，人们发现优先使用组合可以获得复用性与简单性更佳的设计
• 并非不要使用继承，并非继承一无是处，而是不要滥用继承。合成/聚合也有自己的缺点
• 优先使用对象组合，而不是类继承。使用继承必须符合里氏替代原则

单一职责原则	★★★
开闭原则	★★★★★
里氏代换原则	★★★
依赖倒置原则	★★★★
接口分离原则	★★★
迪米特原则	★★
组合/聚合复用原则	★★★★

装饰模式

1、基本原理
在软件系统中，有时候我们会使用继承来扩展对象的功能，但是由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀。如何使“对象功能的扩展”能够根据需要来动态地实现？同时避免“扩展功能的增多”带来的子类膨胀问题？从而使得任何“功能扩展变化”所导致的影响将为最低？这就是本文要讲的Decorator模式。
装饰模式（别名Wrapper）是在不必改变原类文件和使用继承的情况下，动态的扩展一个对象的功能。它通过创建一个包装对象，也就是装饰来包裹真实对象，提供了比继承更具弹性的代替方案。
装饰模式一般涉及到的角色
抽象构建角色(Component):给出一个抽象的接口，以规范准备接受附加责任的对象。
具体的构建角色(ConcreteComponent)：定义一个将要接受附加责任的类。
抽象的装饰角色 (Decorator):持有一个抽象构建(Component)角色的引用，并定义一个与抽象构件一致的接口。
具体的装饰角色(ConcreteDecorator):负责给构建对象“贴上”附加的责任。

2、优缺点
优点
Decorator模式与继承关系的目的都是要扩展对象的功能，但是Decorator可以提供比继承更多的灵活性。
把类中的装饰功能从类中搬移出去，这样可以简化原有的类。有效地把类的核心功能和装饰功能区分开了。
通过使用不同的具体装饰类以及这些装饰类的排列组合，可创造出很多不同行为的组合。
缺点
这种比继承更加灵活机动的特性，也同时意味着更加多的复杂性。
装饰模式会导致设计中出现许多小类，如果过度使用，会使程序变得很复杂。
符合的设计原则：
多用组合，少用继承。利用继承设计子类的行为是在编译时静态决定的，且所有的子类都会继承到相同的行为。如能够利用组合扩展对象的行为，就可在运行时动态进行扩展。
类应设计的对扩展开放，对修改关闭。
3、适用情况
1. 需要扩展一个类的功能，或给一个类添加附加职责。
2. 需要动态的给一个对象添加功能，这些功能可以再动态的撤销。
3. 需要增加由一些基本功能的排列组合而产生的非常大量的功能，从而使继承关系变的不现实。
4. 当不能采用生成子类的方法进行扩充时。一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类。

4、应用举例
1、送生日蛋糕：
MM们要过生日了，怎么也得表示下吧。最起码先送个蛋糕。蛋糕多种多样了。巧克力，冰淇淋，奶油等等。这都是基本的了，再加点额外的装饰，如蛋糕里放点花、放贺卡、放点干果吃着更香等等。
分析：
方案1:如果采用继承会造成大量的蛋糕子类
方案2、蛋糕作为主体，花，贺卡，果仁等是装饰者，需要时加到蛋糕上。要啥我就加啥。

2、极品飞车喷涂鸦：
“极品飞车”这款游戏中有对汽车进行喷涂鸦的功能，而且这个喷涂鸦是可以覆盖的，并且覆盖的顺序也影响到最后车身的显示效果，比如可以是红色火焰、紫色霞光等

3、Java I/O API
java IO中需要完成对不同输入输出源的操作，如果单纯的使用继承这一方式，无疑需要很多的类。比如说，我们操作文件需要一个类，实现文件的字节读取需要一个类，实现文件的字符读取又需要一个类….一次类推每个特定的操作都需要一个特定的类。这无疑会导致大量的IO继承类的出现。显然对于编程是很不利的。
而是用装饰模式则可以很好的解决这一问题，在装饰模式中：节点流（如FileInputStream）直接与输入源交互，之后通过过滤流（FilterInputStream）进行装饰，这样获得的io对象便具有某几个的功能，很好的拓展了IO的功能。

下面拿这个例子来说明一下装饰模式：
1、送生日蛋糕：
MM们要过生日了，怎么也得表示下吧。最起码先送个蛋糕。蛋糕多种多样了。巧克力，冰淇淋，奶油等等。这都是基本的了，再加点额外的装饰，如蛋糕里放点花、放贺卡、放点干果吃着更香等等。
分析：
方案1:如果采用继承会造成大量的蛋糕子类
方案2、蛋糕作为主体，花，贺卡，果仁等是装饰者，需要时加到蛋糕上。要啥我就加啥。

类：
cake
ChocolatorCake
CreamCake
IceCreamCake
Decorator
CardDecorator
FlowerDecorator
NutDecorator
Test类
cake：

/**
 * 蛋糕父类
 * @author Administrator
 *
 */
public abstract class Cake {
    /**
     * 制作蛋糕
     */
    public abstract void make();
}

ChocolatorCake：

public class ChocolatorCake extends Cake{

    @Override
    public void make() {
        System.out.println("制作巧克力蛋糕一个");

    }

}

CreamCake

public class CreamCake extends Cake{

    @Override
    public void make() {
        System.out.println("制作奶油蛋糕一个");

    }

}

Decorator：

/**
 * 装饰的父类
 * 
 * 
 * @author Administrator
 *
 */
public abstract class Decorator extends Cake {//继承Cake类，或者实现Cake接口，目的具有了make()

    private Cake cake = null;//关联一个cake，可以指向任何一个子类对象

    public Decorator(Cake cake) {
        super();
        this.cake = cake;
    }


    @Override
    public void make() {
        cake.make();//这是在制作哪种蛋糕，不确定，要看具体传入的子类对象

    }
}

CardDecorator：

public class CardDecorator extends Decorator{

    public CardDecorator(Cake cake) {
        super(cake);

    }

    @Override
    public void make() {
        //调用父类的make()方法 ？？？？
        super.make();
        //添加自己的功能
        System.out.println("添加一张卡片");
    }


}

FlowerDecorator：

public class FlowerDecorator extends Decorator{

    public FlowerDecorator(Cake cake) {
        super(cake);

    }

    @Override
    public void make() {
        //1.调用父类的make() ???
        super.make();

        //2.添加自己的功能
        System.out.println("放上一朵鲜花");
    }


}

NutDecorator：

public class NutDecorator extends Decorator{

    public NutDecorator(Cake cake) {
        super(cake);

    }

    @Override
    public void make() {
        //1.调用父类的make()
        super.make();

        //2.添加自己的功能
        System.out.println("撒上一些干果");
    }

}

Test类：

public class Test {

    public static void main(String[] args) {
        //订蛋糕
        //1.蛋糕主类型
        Cake cake = new ChocolatorCake();

        //2.添加干果装饰
        Cake cake2 = new NutDecorator(cake);


        //3.添加卡片装饰
        Cake cake3 = new CardDecorator(cake2);

        //4.添加鲜花装饰
        Cake cake4 = new FlowerDecorator(cake3);

        //作蛋糕
        //cake4.make();


        //合并订单
        Cake cake5 = new CardDecorator(new FlowerDecorator(new NutDecorator(new CreamCake())));
        cake5.make();

    }

}