+
+
+
+### 传统方案解决手机操作问题分析
+
+传统方法对应的类图
+
+
+
+1. 扩展性问题(**类爆炸**)，如果我们再增加手机的样式(旋转式)，就需要增加各个品牌手机的类，同样如果我们增加一个手机品牌，也要在各个手机样式类下增加。
+2. 违反了单一职责原则，当我们增加手机样式时，要同时增加所有品牌的手机，这样增加了代码维护成本.
+3. 解决方案-使用**桥接模**式
+4. Bridge 模式基于类的最小设计原则，通过使用封装、聚合及继承等行为让不同的类承担不同的职责。它的主要特点是把抽象(Abstraction)与行为实现(Implementation)分离开来，从而可以保持各部分的独立性以及应对他们的功能扩展
+
+### 使用桥接模式的代码
+
+#### Brand【接口】
+
+```java
+//接口
+public interface Brand {
+ void open();
+ void close();
+ void call();
+}
+```
+
+#### Phone【抽象类】
+
+```java
+public abstract class Phone {
+
+ //组合品牌
+ private Brand brand;
+
+ //构造器
+ public Phone(Brand brand) {
+ super();
+ this.brand = brand;
+ }
+
+ protected void open() {
+ this.brand.open();
+ }
+ protected void close() {
+ brand.close();
+ }
+ protected void call() {
+ brand.call();
+ }
+
+}
+```
+
+#### Vivo
+
+```java
+public class Vivo implements Brand {
+
+ @Override
+ public void open() {
+ // TODO Auto-generated method stub
+ System.out.println(" Vivo手机开机 ");
+ }
+
+ @Override
+ public void close() {
+ // TODO Auto-generated method stub
+ System.out.println(" Vivo手机关机 ");
+ }
+
+ @Override
+ public void call() {
+ // TODO Auto-generated method stub
+ System.out.println(" Vivo手机打电话 ");
+ }
+
+}
+```
+
+#### XiaoMi
+
+```java
+public class XiaoMi implements Brand {
+
+ @Override
+ public void open() {
+ // TODO Auto-generated method stub
+ System.out.println(" 小米手机开机 ");
+ }
+
+ @Override
+ public void close() {
+ // TODO Auto-generated method stub
+ System.out.println(" 小米手机关机 ");
+ }
+
+ @Override
+ public void call() {
+ // TODO Auto-generated method stub
+ System.out.println(" 小米手机打电话 ");
+ }
+
+}
+```
+
+
+
+#### FoldedPhone
+
+```java
+//折叠式手机类，继承 抽象类 Phone
+public class FoldedPhone extends Phone {
+
+ //构造器
+ public FoldedPhone(Brand brand) {
+ super(brand);
+ }
+
+ public void open() {
+ super.open();
+ System.out.println(" 折叠样式手机 ");
+ }
+
+ public void close() {
+ super.close();
+ System.out.println(" 折叠样式手机 ");
+ }
+
+ public void call() {
+ super.call();
+ System.out.println(" 折叠样式手机 ");
+ }
+}
+```
+
+
+
+#### UpRightPhone
+
+```java
+public class UpRightPhone extends Phone {
+
+ //构造器
+ public UpRightPhone(Brand brand) {
+ super(brand);
+ }
+
+ public void open() {
+ super.open();
+ System.out.println(" 直立样式手机 ");
+ }
+
+ public void close() {
+ super.close();
+ System.out.println(" 直立样式手机 ");
+ }
+
+ public void call() {
+ super.call();
+ System.out.println(" 直立样式手机 ");
+ }
+}
+```
+
+
+
+#### Client
+
+```
+public class Client {
+
+ public static void main(String[] args) {
+
+ //获取折叠式手机 (样式 + 品牌 )
+
+ Phone phone1 = new FoldedPhone(new XiaoMi());
+
+ phone1.open();
+ phone1.call();
+ phone1.close();
+
+ System.out.println("=======================");
+
+ Phone phone2 = new FoldedPhone(new Vivo());
+
+ phone2.open();
+ phone2.call();
+ phone2.close();
+
+ System.out.println("==============");
+
+ UpRightPhone phone3 = new UpRightPhone(new XiaoMi());
+
+ phone3.open();
+ phone3.call();
+ phone3.close();
+
+ System.out.println("==============");
+
+ UpRightPhone phone4 = new UpRightPhone(new Vivo());
+
+ phone4.open();
+ phone4.call();
+ phone4.close();
+ }
+
+}
+```
+
+
+
+> 这种简单的demo例子可能比较好理解桥接模式，下面来看看原理和实际应用
+
+## 桥接模式的原理解析
+
+1. 桥接模式，也叫作桥梁模式，英文是Bridge Design Pattern。这个模式可以说是 23 种设计模式中最难理解的模式之一了。我查阅了比较多的书籍和资料之后发现，对于这个模式有两种不同的理解方式。
+2. 当然，这其中“最纯正”的理解方式，当属 GoF 的《设计模式》一书中对桥接模式的定义。毕竟，这 23 种经典的设计模式，最初就是由这本书总结出来的。在 GoF 的《设计模式》一书中，桥接模式是这么定义的：“Decouple an abstraction from its implementation so that the two can vary independently。”翻译成中文就是：“将抽象和实现解耦，让它们可以独立变化。”
+3. 关于桥接模式，很多书籍、资料中，还有另外一种理解方式：“一个类存在两个（或多个）独立变化的维度，我们通过组合的方式，让这两个（或多个）维度可以独立进行扩展。”通过组合关系来替代继承关系，避免继承层次的指数级爆炸。这种理解方式非常类似于，我们之前讲过的“组合优于继承”设计原则，所以，这里我就不多解释了。我们重点看下 GoF 的理解方式。
+4. GoF 给出的定义非常的简短，单凭这一句话，估计没几个人能看懂是什么意思。所以，我们通过 JDBC 驱动的例子来解释一下。JDBC 驱动是桥接模式的经典应用。我们先来看一下，如何利用 JDBC 驱动来查询数据库。具体的代码如下所示：
+
+
+
+```java
+ Class.forName("com.mysql.jdbc.Driver"); // 加载及注册JDBC驱动程序
+ String url = "jdbc:mysql://localhost:3306/sample_db?user=root&password=your_password";
+ Connection con = DriverManager.getConnection(url);
+ Statement stmt = con.createStatement();
+ String query = "select * from test";
+ ResultSet rs = stmt.executeQuery(query);
+ while (rs.next()) {
+ rs.getString(1);
+ rs.getInt(2);
+ }
+```
+
+
+
+1. 如果我们想要把 MySQL 数据库换成 Oracle 数据库，只需要把第一行代码中的 com.mysql.jdbc.Driver 换成 oracle.jdbc.driver.OracleDriver 就可以了。当然，也有更灵活的实现方式，我们可以把需要加载的 Driver 类写到配置文件中，当程序启动的时候，自动从配置文件中加载，这样在切换数据库的时候，我们都不需要修改代码，只需要修改配置文件就可以了。
+2. 不管是改代码还是改配置，在项目中，从一个数据库切换到另一种数据库，都只需要改动很少的代码，或者完全不需要改动代码，那如此优雅的数据库切换是如何实现的呢？
+3. 源码之下无秘密。要弄清楚这个问题，我们先从 com.mysql.jdbc.Driver 这个类的代码看起。我摘抄了部分相关代码，放到了这里，你可以看一下。
+
+
+
+```java
+package com.mysql.jdbc;
+import java.sql.SQLException;
+
+public class Driver extends NonRegisteringDriver implements java.sql.Driver {
+ static {
+ try {
+ java.sql.DriverManager.registerDriver(new Driver());
+ } catch (SQLException E) {
+ throw new RuntimeException("Can't register driver!");
+ }
+ }
+
+ /**
+ * Construct a new driver and register it with DriverManager
+ * @throws SQLException if a database error occurs.
+ */
+ public Driver() throws SQLException {
+ // Required for Class.forName().newInstance()
+ }
+}
+
+```
+
+
+
+结合 com.mysql.jdbc.Driver 的代码实现，我们可以发现，当执行 Class.forName(“com.mysql.jdbc.Driver”) 这条语句的时候，实际上是做了两件事情。第一件事情是要求 JVM 查找并加载指定的 Driver 类，第二件事情是执行该类的静态代码，也就是将 MySQL Driver 注册到 DriverManager 类中。
+
+
+
+现在，我们再来看一下，DriverManager 类是干什么用的。具体的代码如下所示。当我们把具体的 Driver 实现类（比如，com.mysql.jdbc.Driver）注册到 DriverManager 之后，后续所有对 JDBC 接口的调用，都会委派到对具体的 Driver 实现类来执行。而 Driver 实现类都实现了相同的接口（java.sql.Driver ），这也是可以灵活切换 Driver 的原因。
+
+
+
+```java
+public class DriverManager {
+ private static final CopyOnWriteArrayList
+
+
+
+## 桥接模式的应用举例
+
+在前面，我们讲过一个 API 接口监控告警的例子：根据不同的告警规则，触发不同类型的告警。告警支持多种通知渠道，包括：邮件、短信、微信、自动语音电话。通知的紧急程度有多种类型，包括：SEVERE（严重）、URGENCY（紧急）、NORMAL（普通）、TRIVIAL（无关紧要）。不同的紧急程度对应不同的通知渠道。比如，SERVE（严重）级别的消息会通过“自动语音电话”告知相关人员。
+
+
+
+在当时的代码实现中，关于发送告警信息那部分代码，我们只给出了粗略的设计，现在我们来一块实现一下。我们先来看最简单、最直接的一种实现方式。代码如下所示：
+
+```java
+
+public enum NotificationEmergencyLevel {
+ SEVERE,
+ URGENCY,
+ NORMAL,
+ TRIVIAL
+}
+
+public class Notification {
+ private List
+
+
+
+1. Drink 是一个抽象类，表示饮料
+2. des 就是对咖啡的描述, 比如咖啡的名字
+3. cost() 方法就是计算费用，Drink 类中做成一个抽象方法.
+4. Decaf 就是单品咖啡， 继承 Drink, 并实现 cost
+5. Espress && Milk 就是单品咖啡+调料， 这个组合很多
+6. 问题：**这样设计，会有很多类，当我们增加一个单品咖啡，或者一个新的调料，类的数量就会倍增，就会出现类爆炸**
+
+### 方案二
+
+前面分析到方案 1 因为咖啡单品+调料组合会造成类的倍增，因此可以做改进，将调料内置到 Drink 类，这样就不会造成类数量过多。从而提高项目的维护性(如图)
+
+
+
+
+
+1. 方案 2 可以控制类的数量，不至于造成很多的类
+2. 在增加或者删除调料种类时，代码的维护量很大
+3. 考虑到用户可以添加多份 调料时，可以将 hasMilk 返回一个对应 int
+4. 考虑使用 **装饰者** 模式
+
+> 注意：装饰器模式是对功能的增强，而不是附加新的功能。代理模式才是附加新的功能。
+
+
+
+### 装饰器模式代码
+
+
+
+#### Drink【抽象类-主体Component】
+
+```java
+public abstract class Drink {
+
+ public String des; // 描述
+ private float price = 0.0f;
+ public String getDes() {
+ return des;
+ }
+ public void setDes(String des) {
+ this.des = des;
+ }
+ public float getPrice() {
+ return price;
+ }
+ public void setPrice(float price) {
+ this.price = price;
+ }
+
+ //计算费用的抽象方法
+ //子类来实现
+ public abstract float cost();
+
+}
+```
+
+
+
+#### Decorator
+
+```java
+public class Decorator extends Drink {
+ private Drink obj;
+
+ public Decorator(Drink obj) { //组合
+ // TODO Auto-generated constructor stub
+ this.obj = obj;
+ }
+
+ @Override
+ public float cost() {
+ // TODO Auto-generated method stub
+ // getPrice 自己价格
+ return super.getPrice() + obj.cost();
+ }
+
+ @Override
+ public String getDes() {
+ // TODO Auto-generated method stub
+ // obj.getDes() 输出被装饰者的信息
+ return des + " " + getPrice() + " && " + obj.getDes();
+ }
+
+}
+```
+
+#### Coffee
+
+```
+public class Coffee extends Drink {
+
+ @Override
+ public float cost() {
+ // TODO Auto-generated method stub
+ return super.getPrice();
+ }
+}
+```
+
+#### ShortBlack
+
+```java
+public class ShortBlack extends Coffee{
+
+ public ShortBlack() {
+ setDes(" shortblack ");
+ setPrice(4.0f);
+ }
+}
+```
+
+#### LongBlack
+
+```java
+public class LongBlack extends Coffee {
+
+ public LongBlack() {
+ setDes(" longblack ");
+ setPrice(5.0f);
+ }
+}
+```
+
+#### DeCaf
+
+```java
+public class DeCaf extends Coffee {
+
+ public DeCaf() {
+ setDes(" 无因咖啡 ");
+ setPrice(1.0f);
+ }
+}
+```
+
+#### Espresso
+
+```java
+public class Espresso extends Coffee {
+
+ public Espresso() {
+ setDes(" 意大利咖啡 ");
+ setPrice(6.0f);
+ }
+}
+```
+
+#### Chocolate
+
+```java
+//具体的Decorator， 这里就是调味品
+public class Chocolate extends Decorator {
+
+ public Chocolate(Drink obj) {
+ super(obj);
+ setDes(" 巧克力 ");
+ setPrice(3.0f); // 调味品 的价格
+ }
+
+}
+```
+
+#### Milk
+
+```java
+public class Milk extends Decorator {
+
+ public Milk(Drink obj) {
+ super(obj);
+ // TODO Auto-generated constructor stub
+ setDes(" 牛奶 ");
+ setPrice(2.0f);
+ }
+
+}
+```
+
+#### Soy
+
+```java
+public class Soy extends Decorator{
+
+ public Soy(Drink obj) {
+ super(obj);
+ // TODO Auto-generated constructor stub
+ setDes(" 豆浆 ");
+ setPrice(1.5f);
+ }
+
+}
+```
+
+#### CoffeeBar
+
+```java
+public class CoffeeBar {
+
+ public static void main(String[] args) {
+ // TODO Auto-generated method stub
+ // 装饰者模式下的订单：2份巧克力+一份牛奶的LongBlack
+
+ // 1. 点一份 LongBlack
+ Drink order = new LongBlack();
+ System.out.println("费用1=" + order.cost());
+ System.out.println("描述=" + order.getDes());
+
+ // 2. order 加入一份牛奶
+ order = new Milk(order);
+
+ System.out.println("order 加入一份牛奶 费用 =" + order.cost());
+ System.out.println("order 加入一份牛奶 描述 = " + order.getDes());
+
+ // 3. order 加入一份巧克力
+
+ order = new Chocolate(order);
+
+ System.out.println("order 加入一份牛奶 加入一份巧克力 费用 =" + order.cost());
+ System.out.println("order 加入一份牛奶 加入一份巧克力 描述 = " + order.getDes());
+
+ // 3. order 加入一份巧克力
+
+ order = new Chocolate(order);
+
+ System.out.println("order 加入一份牛奶 加入2份巧克力 费用 =" + order.cost());
+ System.out.println("order 加入一份牛奶 加入2份巧克力 描述 = " + order.getDes());
+
+ System.out.println("===========================");
+
+ Drink order2 = new DeCaf();
+
+ System.out.println("order2 无因咖啡 费用 =" + order2.cost());
+ System.out.println("order2 无因咖啡 描述 = " + order2.getDes());
+
+ order2 = new Milk(order2);
+
+ System.out.println("order2 无因咖啡 加入一份牛奶 费用 =" + order2.cost());
+ System.out.println("order2 无因咖啡 加入一份牛奶 描述 = " + order2.getDes());
+
+
+ }
+
+}
+```
+
+
+
+## 装饰者模式原理
+
+1. 装饰者模式就像打包一个快递
+
+主体：比如：陶瓷、衣服 (Component) // 被装饰者
+
+包装：比如：报纸填充、塑料泡沫、纸板、木板(Decorator)
+
+2. Component 主体：比如类似前面的 Drink
+
+3. ConcreteComponent 和 Decorator
+
+ConcreteComponent：具体的主体， 比如前面的各个单品咖啡
+
+4. Decorator: 装饰者，比如各调料.
+
+在Component 与 ConcreteComponent 之间，如果 ConcreteComponent 类很多,还可以设计一个缓冲层，将 共有的部分提取出来，抽象层一个类
+
+## Java IO 类的“奇怪”用法
+
+Java IO 类库非常庞大和复杂，有几十个类，负责 IO 数据的读取和写入。如果对 Java IO 类做一下分类，我们可以从下面两个维度将它划分为四类。具体如下所示：
+
+| | 字节流 | 字符流 |
+| ------ | ------------ | ------ |
+| 输入流 | InputStream | Reader |
+| 输出流 | OutputStream | Writer |
+
+针对不同的读取和写入场景，Java IO 又在这四个父类基础之上，扩展出了很多子类。具体如下所示：
+
+
+
+
+
+> 说明
+>
+> 1. InputStream 是抽象类, 类似我们前面讲的 Drink
+> 2. FileInputStream 是 InputStream 子类，类似我们前面的 DeCaf, LongBlack
+> 3. FilterInputStream 是 InputStream 子类：类似我们前面 的 Decorator 修饰者
+> 4. DataInputStream 是 FilterInputStream 子类，具体的修饰者，类似前面的 Milk, Soy 等
+> 5. FilterInputStream 类 有 protected volatile InputStream in; 即含被装饰者
+> 6. 分析得出在jdk 的io体系中，就是使用装饰者模式
+
+在我初学 Java 的时候，曾经对 Java IO 的一些用法产生过很大疑惑，比如下面这样一段代码。我们打开文件 test.txt，从中读取数据。其中，InputStream 是一个抽象类，FileInputStream 是专门用来读取文件流的子类。BufferedInputStream 是一个支持带缓存功能的数据读取类，可以提高数据读取的效率。
+
+
+
+```java
+InputStream in = new FileInputStream("/user/test.txt");
+InputStream bin = new BufferedInputStream(in);
+byte[] data = new byte[128];
+while (bin.read(data) != -1) {
+ //...
+}
+```
+
+初看上面的代码，我们会觉得 Java IO 的用法比较麻烦，需要先创建一个 FileInputStream 对象，然后再传递给 BufferedInputStream 对象来使用。我在想，Java IO 为什么不设计一个继承 FileInputStream 并且支持缓存的 BufferedFileInputStream 类呢？这样我们就可以像下面的代码中这样，直接创建一个 BufferedFileInputStream 类对象，打开文件读取数据，用起来岂不是更加简单？
+
+
+
+```java
+InputStream bin = new BufferedFileInputStream("/user/test.txt");
+byte[] data = new byte[128];
+while (bin.read(data) != -1) {
+ //...
+}
+```
+
+
+
+
+
+## 基于继承的设计方案
+
+如果 InputStream 只有一个子类 FileInputStream 的话，那我们在 FileInputStream 基础之上，再设计一个孙子类 BufferedFileInputStream，也算是可以接受的，毕竟继承结构还算简单。但实际上，继承 InputStream 的子类有很多。我们需要给每一个 InputStream 的子类，再继续派生支持缓存读取的子类。
+
+
+
+除了支持缓存读取之外，如果我们还需要对功能进行其他方面的增强，比如下面的 DataInputStream 类，支持按照基本数据类型（int、boolean、long 等）来读取数据。
+
+```java
+FileInputStream in = new FileInputStream("/user/test.txt");
+DataInputStream din = new DataInputStream(in);
+int data = din.readInt();
+```
+
+在这种情况下，如果我们继续按照继承的方式来实现的话，就需要再继续派生出 DataFileInputStream、DataPipedInputStream 等类。如果我们还需要既支持缓存、又支持按照基本类型读取数据的类，那就要再继续派生出 BufferedDataFileInputStream、BufferedDataPipedInputStream 等 n 多类。这还只是附加了两个增强功能，如果我们需要附加更多的增强功能，那就会导致组合爆炸，类继承结构变得无比复杂，代码既不好扩展，也不好维护。这也是我们不推荐使用继承的原因。
+
+
+
+## 基于装饰器模式的设计方案
+
+
+
+在前面，我们还讲到“组合优于继承”，可以“使用组合来替代继承”。针对刚刚的继承结构过于复杂的问题，我们可以通过将继承关系改为组合关系来解决。下面的代码展示了 Java IO 的这种设计思路。不过，我对代码做了简化，只抽象出了必要的代码结构，如果你感兴趣的话，可以直接去查看 JDK 源码。
+
+```java
+import java.io.IOException;
+
+public abstract class InputStream {
+ // ...
+ public int read(byte b[]) throws IOException {
+ return read(b, 0, b.length);
+ }
+ public int read(byte b[], int off, int len) throws IOException {
+ // ...
+ }
+
+ public long skip(long n) throws IOException {
+ // ...
+ }
+
+ public int available() throws IOException {
+ return 0;
+ }
+
+ public void close() throws IOException {}
+
+ public synchronized void mark(int readlimit) {}
+
+ public synchronized void reset() throws IOException {
+ throw new IOException("mark/reset not supported");
+ }
+
+ public boolean markSupported() {
+ return false;
+ }
+}
+
+public class BufferedInputStream extends InputStream {
+ protected volatile InputStream in;
+
+ protected BufferedInputStream(InputStream in) {
+ this.in = in;
+ }
+
+ // ...实现基于缓存的读数据接口...
+}
+
+public class DataInputStream extends InputStream {
+ protected volatile InputStream in;
+
+ protected DataInputStream(InputStream in) {
+ this.in = in;
+ }
+
+ // ...实现读取基本类型数据的接口
+}
+
+```
+
+看了上面的代码，你可能会问，那装饰器模式就是简单的“用组合替代继承”吗？当然不是。从 Java IO 的设计来看，装饰器模式相对于简单的组合关系，还有两个比较特殊的地方。
+
+
+
+**第一个比较特殊的地方是：装饰器类和原始类继承同样的父类，这样我们可以对原始类“嵌套”多个装饰器类。**比如，下面这样一段代码，我们对 FileInputStream 嵌套了两个装饰器类：BufferedInputStream 和 DataInputStream，让它既支持缓存读取，又支持按照基本数据类型来读取数据。
+
+
+
+```java
+InputStream in = new FileInputStream("/user/test.txt");
+InputStream bin = new BufferedInputStream(in);
+DataInputStream din = new DataInputStream(bin);
+int data = din.readInt();
+```
+
+
+
+**第二个比较特殊的地方是：装饰器类是对功能的增强，这也是装饰器模式应用场景的一个重要特点。**实际上，符合“组合关系”这种代码结构的设计模式有很多，比如之前讲过的代理模式、桥接模式，还有现在的装饰器模式。尽管它们的代码结构很相似，但是每种设计模式的意图是不同的。就拿比较相似的代理模式和装饰器模式来说吧，代理模式中，代理类附加的是跟原始类无关的功能，而在装饰器模式中，装饰器类附加的是跟原始类相关的增强功能。
+
+```java
+// 代理模式的代码结构(下面的接口也可以替换成抽象类)
+public interface IA {
+ void f();
+}
+
+public class A impelements IA {
+ public void f() {
+ //...
+ }
+}
+
+public class AProxy impements IA {
+ private IA a;
+
+ public AProxy(IA a) {
+ this.a = a;
+ }
+
+ public void f() {
+ // 新添加的代理逻辑
+ a.f();
+ // 新添加的代理逻辑
+ }
+}
+
+// 装饰器模式的代码结构(下面的接口也可以替换成抽象类)
+public interface IA {
+ void f();
+}
+
+public class A impelements IA {
+
+ public void f() {
+ //...
+ }
+}
+
+public class ADecorator impements IA {
+ private IA a;
+ public ADecorator(IA a) {
+ this.a = a;
+ }
+
+ public void f() {
+ // 功能增强代码
+ a.f();
+ // 功能增强代码
+ }
+}
+```
+
+
+
+1. 实际上，如果去查看 JDK 的源码，你会发现，BufferedInputStream、DataInputStream 并非继承自 InputStream，而是另外一个叫 FilterInputStream 的类。那这又是出于什么样的设计意图，才引入这样一个类呢？
+2. 我们再重新来看一下 BufferedInputStream 类的代码。InputStream 是一个抽象类而非接口，而且它的大部分函数（比如 read()、available()）都有默认实现，按理来说，我们只需要在 BufferedInputStream 类中重新实现那些需要增加缓存功能的函数就可以了，其他函数继承 InputStream 的默认实现。但实际上，这样做是行不通的。
+3. 对于即便是不需要增加缓存功能的函数来说，BufferedInputStream 还是必须把它重新实现一遍，简单包裹对 InputStream 对象的函数调用。具体的代码示例如下所示。如果不重新实现，那 BufferedInputStream 类就无法将最终读取数据的任务，委托给传递进来的 InputStream 对象来完成。这一部分稍微有点不好理解，你自己多思考一下。
+
+
+
+```java
+public class BufferedInputStream extends InputStream {
+ protected volatile InputStream in;
+
+ protected BufferedInputStream(InputStream in) {
+ this.in = in;
+ }
+
+ // f()函数不需要增强，只是重新调用一下InputStream in对象的f()
+ public void f() {
+ in.f();
+ }
+}
+```
+
+
+
+实际上，DataInputStream 也存在跟 BufferedInputStream 同样的问题。为了避免代码重复，Java IO 抽象出了一个装饰器父类 FilterInputStream，代码实现如下所示。InputStream 的所有的装饰器类（BufferedInputStream、DataInputStream）都继承自这个装饰器父类。这样，装饰器类只需要实现它需要增强的方法就可以了，其他方法继承装饰器父类的默认实现。
+
+
+
+```java
+
+public class FilterInputStream extends InputStream {
+ protected volatile InputStream in;
+
+ protected FilterInputStream(InputStream in) {
+ this.in = in;
+ }
+
+ public int read() throws IOException {
+ return in.read();
+ }
+
+ public int read(byte b[]) throws IOException {
+ return read(b, 0, b.length);
+ }
+
+ public int read(byte b[], int off, int len) throws IOException {
+ return in.read(b, off, len);
+ }
+
+ public long skip(long n) throws IOException {
+ return in.skip(n);
+ }
+
+ public int available() throws IOException {
+ return in.available();
+ }
+
+ public void close() throws IOException {
+ in.close();
+ }
+
+ public synchronized void mark(int readlimit) {
+ in.mark(readlimit);
+ }
+
+ public synchronized void reset() throws IOException {
+ in.reset();
+ }
+
+ public boolean markSupported() {
+ return in.markSupported();
+ }
+
+}
+```
+
+
+
+
+
+# 适配器模式【常用】
+
+1. 前面我们学了代理模式、桥接模式、装饰器模式，今天，我们再来学习一个比较常用的结构型模式：适配器模式。这个模式相对来说还是比较简单、好理解的，应用场景也很具体，总体上来讲比较好掌握。
+2. 关于适配器模式，今天我们主要学习它的两种实现方式，类适配器和对象适配器，以及 5 种常见的应用场景。同时，我还会通过剖析 slf4j 日志框架，来给你展示这个模式在真实项目中的应用。除此之外，在文章的最后，我还对代理、桥接、装饰器、适配器，这 4 种代码结构非常相似的设计模式做简单的对比，对这几节内容做一个简单的总结。
+3. 适配器模式(Adapter Pattern)将某个类的接口转换成客户端期望的另一个接口表示，**主的目的是兼容性**，让原本因接口不匹配不能一起工作的两个类可以协同工作。其别名为包装器(Wrapper) 。适配器模式属于结构型模式。主要分为三类：**类适配器模式、对象适配器模式、接口适配器模**式
+
+
+
+## Demo案例-充电器
+
+基本介绍：Adapter 类，通过继承 src 类，实现 dst 类接口，完成 src->dst 的适配。
+
+- 以生活中充电器的例子来讲解适配器，充电器本身相当于 Adapter，220V 交流电相当于 src (即被适配者)，我们 的目 dst(即 目标)是 5V 直流电
+
+### 类适配器代码实现
+
+#### Voltage220V
+
+```java
+//被适配的类
+public class Voltage220V {
+ //输出220V的电压
+ public int output220V() {
+ int src = 220;
+ System.out.println("电压=" + src + "伏");
+ return src;
+ }
+}
+```
+
+#### IVoltage5V
+
+```java
+//适配接口
+public interface IVoltage5V {
+ public int output5V();
+}
+```
+
+#### Phone
+
+```java
+public class Phone {
+
+ //充电
+ public void charging(IVoltage5V iVoltage5V) {
+ if(iVoltage5V.output5V() == 5) {
+ System.out.println("电压为5V, 可以充电~~");
+ } else if (iVoltage5V.output5V() > 5) {
+ System.out.println("电压大于5V, 不能充电~~");
+ }
+ }
+}
+```
+
+#### VoltageAdapter
+
+```java
+//适配器类
+public class VoltageAdapter extends Voltage220V implements IVoltage5V {
+
+ @Override
+ public int output5V() {
+ // TODO Auto-generated method stub
+ //获取到220V电压
+ int srcV = output220V();
+ int dstV = srcV / 44 ; //转成 5v
+ return dstV;
+ }
+
+}
+```
+
+#### Client
+
+```java
+public class Client {
+
+ public static void main(String[] args) {
+ // TODO Auto-generated method stub
+ System.out.println(" === 类适配器模式 ====");
+ Phone phone = new Phone();
+ phone.charging(new VoltageAdapter());
+ }
+
+}
+```
+
+
+
+### 对象适配器实现
+
+基本思路和类的适配器模式相同，只是将 Adapter 类作修改，不是继承 src 类，而是持有 src 类的实例，以解决 兼容性的问题。 即：持有 src 类，实现 dst 类接口，完成 src->dst 的适配 ，在系统中尽量使用**关联关系（聚合，组合）来替代继承**关系。
+
+
+
+上面的例子代码基本没用什么改变，改变的只有以下两个类
+
+#### VoltageAdapter
+
+```java
+// 适配器类
+public class VoltageAdapter implements IVoltage5V {
+
+ private Voltage220V voltage220V; // 关联关系-聚合
+
+ // 通过构造器，传入一个 Voltage220V 实例
+ public VoltageAdapter(Voltage220V voltage220v) {
+
+ this.voltage220V = voltage220v;
+ }
+
+ @Override
+ public int output5V() {
+
+ int dst = 0;
+ if (null != voltage220V) {
+ int src = voltage220V.output220V(); // 获取220V 电压
+ System.out.println("使用对象适配器，进行适配~~");
+ dst = src / 44;
+ System.out.println("适配完成，输出的电压为=" + dst);
+ }
+
+ return dst;
+ }
+}
+```
+
+#### Client
+
+```java
+public class Client {
+
+ public static void main(String[] args) {
+ // TODO Auto-generated method stub
+ System.out.println(" === 对象适配器模式 ====");
+ Phone phone = new Phone();
+ phone.charging(new VoltageAdapter(new Voltage220V()));
+ }
+}
+```
+
+
+
+
+
+## 适配器模式的原理与实现
+
+顾名思义，这个模式就是用来做适配的，它将不兼容的接口转换为可兼容的接口，让原本由于接口不兼容而不能一起工作的类可以一起工作。对于这个模式，有一个经常被拿来解释它的例子，就是 USB 转接头充当适配器，把两种不兼容的接口，通过转接变得可以一起工作。
+
+
+
+原理很简单，我们再来看下它的代码实现。适配器模式有两种实现方式：类适配器和对象适配器。其中，类适配器使用继承关系来实现，对象适配器使用组合关系来实现。具体的代码实现如下所示。其中，ITarget 表示要转化成的接口定义。Adaptee 是一组不兼容 ITarget 接口定义的接口，Adaptor 将 Adaptee 转化成一组符合 ITarget 接口定义的接口。
+
+```java
+// 类适配器: 基于继承
+public interface ITarget {
+ void f1();
+ void f2();
+ void fc();
+}
+
+public class Adaptee {
+
+ public void fa() {
+ //...
+ }
+
+ public void fb() {
+ //...
+ }
+
+ public void fc(){
+ //...
+ }
+
+}
+
+public class Adaptor extends Adaptee implements ITarget {
+
+ public void f1() {
+ super.fa();
+ }
+
+ public void f2() {
+ //...重新实现f2()...
+ }
+
+// 这里fc()不需要实现，直接继承自Adaptee，这是跟对象适配器最大的不同点
+}
+
+// 对象适配器：基于组合
+public interface ITarget {
+ void f1();
+ void f2();
+ void fc();
+}
+public class Adaptee {
+
+ public void fa() {
+ //...
+ }
+
+ public void fb() {
+ //...
+ }
+
+ public void fc(){
+ //...
+ }
+
+}
+
+public class Adaptor implements ITarget {
+ private Adaptee adaptee;
+
+ public Adaptor(Adaptee adaptee) {
+ this.adaptee = adaptee;
+ }
+
+ public void f1() {
+ adaptee.fa(); //委托给Adaptee
+ }
+
+ public void f2() {
+ //...重新实现f2()...
+ }
+
+ public void fc() {
+ adaptee.fc();
+ }
+}
+```
+
+
+
+针对这两种实现方式，在实际的开发中，到底该如何选择使用哪一种呢？判断的标准主要有两个，一个是 Adaptee 接口的个数，另一个是 Adaptee 和 ITarget 的契合程度。
+
+- 如果 Adaptee 接口并不多，那两种实现方式都可以。
+- 如果 Adaptee 接口很多，而且 Adaptee 和 ITarget 接口定义大部分都相同，那我们推荐使用类适配器，因为 Adaptor 复用父类 Adaptee 的接口，比起对象适配器的实现方式，Adaptor 的代码量要少一些。
+- 如果 Adaptee 接口很多，而且 Adaptee 和 ITarget 接口定义大部分都不相同，那我们推荐使用对象适配器，因为组合结构相对于继承更加灵活。
+
+
+
+## 适配器模式应用场景总结
+
+1. 原理和实现讲完了，都不复杂。我们再来看，到底什么时候会用到适配器模式呢？
+
+2. 一般来说，适配器模式可以看作一种“补偿模式”，用来补救设计上的缺陷。应用这种模式算是“无奈之举”。如果在设计初期，我们就能协调规避接口不兼容的问题，那这种模式就没有应用的机会了。
+3. 前面我们反复提到，适配器模式的应用场景是“接口不兼容”。那在实际的开发中，什么情况下才会出现接口不兼容呢？我建议你先自己思考一下这个问题，然后再来看下面的总结 。
+
+
+
+### 封装有缺陷的接口设计
+
+1. 假设我们依赖的外部系统在接口设计方面有缺陷（比如包含大量静态方法），引入之后会影响到我们自身代码的可测试性。为了隔离设计上的缺陷，我们希望对外部系统提供的接口进行二次封装，抽象出更好的接口设计，这个时候就可以使用适配器模式了。
+
+2. 具体我还是举个例子来解释一下，你直接看代码应该会更清晰。具体代码如下所示：
+
+```java
+public class CD { //这个类来自外部sdk，我们无权修改它的代码
+ //...
+ public static void staticFunction1() { //... }
+
+ public void uglyNamingFunction2() { //... }
+
+ public void tooManyParamsFunction3(int paramA, int paramB, ...) { //... }
+
+ public void lowPerformanceFunction4() { //... }
+
+}
+
+// 使用适配器模式进行重构
+public class ITarget {
+
+ void function1();
+ void function2();
+ void fucntion3(ParamsWrapperDefinition paramsWrapper);
+ void function4();
+ //...
+}
+
+// 注意：适配器类的命名不一定非得末尾带Adaptor
+
+public class CDAdaptor extends CD implements ITarget {
+ //...
+ public void function1() {
+ super.staticFunction1();
+ }
+
+ public void function2() {
+ super.uglyNamingFucntion2();
+ }
+
+ public void function3(ParamsWrapperDefinition paramsWrapper) {
+ super.tooManyParamsFunction3(paramsWrapper.getParamA(), ...);
+ }
+
+ public void function4() {
+ //...reimplement it...
+ }
+}
+```
+
+
+
+### 统一多个类的接口设计
+
+1. 某个功能的实现依赖多个外部系统（或者说类）。通过适配器模式，将它们的接口适配为统一的接口定义，然后我们就可以使用多态的特性来复用代码逻辑。具体我还是举个例子来解释一下。
+2. 假设我们的系统要对用户输入的文本内容做敏感词过滤，为了提高过滤的召回率，我们引入了多款第三方敏感词过滤系统，依次对用户输入的内容进行过滤，过滤掉尽可能多的敏感词。但是，每个系统提供的过滤接口都是不同的。这就意味着我们没法复用一套逻辑来调用各个系统。这个时候，我们就可以使用适配器模式，将所有系统的接口适配为统一的接口定义，这样我们可以复用调用敏感词过滤的代码。
+3. 你可以配合着下面的代码示例，来理解我刚才举的这个例子。
+
+```java
+import java.util.ArrayList;
+import java.util.List;
+
+public class ASensitiveWordsFilter { // A敏感词过滤系统提供的接口
+ // text是原始文本，函数输出用***替换敏感词之后的文本
+ public String filterSexyWords(String text) {
+ // ...
+ }
+
+ public String filterPoliticalWords(String text) {
+ // ...
+ }
+}
+
+public class BSensitiveWordsFilter { // B敏感词过滤系统提供的接口
+ public String filter(String text) {
+ // ...
+ }
+}
+
+public class CSensitiveWordsFilter { // C敏感词过滤系统提供的接口
+ public String filter(String text, String mask) {
+ // ...
+ }
+}
+
+// 未使用适配器模式之前的代码：代码的可测试性、扩展性不好
+public class RiskManagement {
+ private ASensitiveWordsFilter aFilter = new ASensitiveWordsFilter();
+ private BSensitiveWordsFilter bFilter = new BSensitiveWordsFilter();
+ private CSensitiveWordsFilter cFilter = new CSensitiveWordsFilter();
+
+ public String filterSensitiveWords(String text) {
+ String maskedText = aFilter.filterSexyWords(text);
+ maskedText = aFilter.filterPoliticalWords(maskedText);
+ maskedText = bFilter.filter(maskedText);
+ maskedText = cFilter.filter(maskedText, "***");
+ return maskedText;
+ }
+}
+
+// 使用适配器模式进行改造
+public interface ISensitiveWordsFilter { // 统一接口定义
+ String filter(String text);
+}
+
+public class ASensitiveWordsFilterAdaptor implements ISensitiveWordsFilter {
+ private ASensitiveWordsFilter aFilter;
+
+ public String filter(String text) {
+ String maskedText = aFilter.filterSexyWords(text);
+ maskedText = aFilter.filterPoliticalWords(maskedText);
+ return maskedText;
+ }
+}
+
+// ...省略BSensitiveWordsFilterAdaptor、CSensitiveWordsFilterAdaptor...
+// 扩展性更好，更加符合开闭原则，如果添加一个新的敏感词过滤系统，
+// 这个类完全不需要改动；而且基于接口而非实现编程，代码的可测试性更好。
+public class RiskManagement {
+ private List
+
+1. 在 ClientTest 的 main 方法中，创建各个子系统的对象，并直接去调用子系统(对象)相关方法，会造成调用过程 混乱，没有清晰的过程 不利于在 ClientTest 中，去维护对子系统的操作
+
+2. 解决思路：**定义一个高层接口**，给**子系统中的一组接口提供一个一致的界面**(比如在高层接口提供四个方法 ready, play, pause, end )，用来访问子系统中的一群接口
+
+3. 也就是说 就是通过定义一个一致的接口(界面类)，用以屏蔽内部子系统的细节，使得调用端只需跟这个接口发 生调用，而无需关心这个子系统的内部细节 => **外观模式**
+4. 外观类(Facade): 为调用端提供统一的调用接口, 外观类知道哪些子系统负责处理请求,从而将调用端的请求代 理给适当子系统对象
+5. 调用者(Client): 外观接口的调用者
+6. 子系统的集合：指模块或者子系统，处理 Facade 对象指派的任务，他是功能的实际提供者
+
+
+
+### 门面模式代码
+
+#### TheaterLight
+
+```java
+public class TheaterLight {
+
+ private static TheaterLight instance = new TheaterLight();
+
+ public static TheaterLight getInstance() {
+ return instance;
+ }
+
+ public void on() {
+ System.out.println(" TheaterLight on ");
+ }
+
+ public void off() {
+ System.out.println(" TheaterLight off ");
+ }
+
+ public void dim() {
+ System.out.println(" TheaterLight dim.. ");
+ }
+
+ public void bright() {
+ System.out.println(" TheaterLight bright.. ");
+ }
+}
+```
+
+#### Stereo
+
+```java
+public class Stereo {
+
+ private static Stereo instance = new Stereo();
+
+ public static Stereo getInstance() {
+ return instance;
+ }
+
+ public void on() {
+ System.out.println(" Stereo on ");
+ }
+
+ public void off() {
+ System.out.println(" Screen off ");
+ }
+
+ public void up() {
+ System.out.println(" Screen up.. ");
+ }
+
+ //...
+}
+```
+
+#### Screen
+
+```java
+public class Screen {
+
+ private static Screen instance = new Screen();
+
+ public static Screen getInstance() {
+ return instance;
+ }
+
+ public void up() {
+ System.out.println(" Screen up ");
+ }
+
+ public void down() {
+ System.out.println(" Screen down ");
+ }
+
+}
+```
+
+#### Projector
+
+```
+public class Projector {
+
+ private static Projector instance = new Projector();
+
+ public static Projector getInstance() {
+ return instance;
+ }
+
+ public void on() {
+ System.out.println(" Projector on ");
+ }
+
+ public void off() {
+ System.out.println(" Projector ff ");
+ }
+
+ public void focus() {
+ System.out.println(" Projector is Projector ");
+ }
+
+ //...
+}
+```
+
+#### Popcorn
+
+```
+public class Popcorn {
+
+ private static Popcorn instance = new Popcorn();
+
+ public static Popcorn getInstance() {
+ return instance;
+ }
+
+ public void on() {
+ System.out.println(" popcorn on ");
+ }
+
+ public void off() {
+ System.out.println(" popcorn ff ");
+ }
+
+ public void pop() {
+ System.out.println(" popcorn is poping ");
+ }
+}
+```
+
+#### DVDPlayer
+
+```
+public class DVDPlayer {
+
+ //使用单例模式, 使用饿汉式
+ private static DVDPlayer instance = new DVDPlayer();
+
+ public static DVDPlayer getInstanc() {
+ return instance;
+ }
+
+ public void on() {
+ System.out.println(" dvd on ");
+ }
+ public void off() {
+ System.out.println(" dvd off ");
+ }
+
+ public void play() {
+ System.out.println(" dvd is playing ");
+ }
+
+ //....
+ public void pause() {
+ System.out.println(" dvd pause ..");
+ }
+}
+```
+
+
+
+#### HomeTheaterFacade
+
+```java
+
+public class HomeTheaterFacade {
+
+ // 定义各个子系统对象
+ private TheaterLight theaterLight;
+ private Popcorn popcorn;
+ private Stereo stereo;
+ private Projector projector;
+ private Screen screen;
+ private DVDPlayer dVDPlayer;
+
+ // 构造器
+ public HomeTheaterFacade() {
+ super();
+ this.theaterLight = TheaterLight.getInstance();
+ this.popcorn = Popcorn.getInstance();
+ this.stereo = Stereo.getInstance();
+ this.projector = Projector.getInstance();
+ this.screen = Screen.getInstance();
+ this.dVDPlayer = DVDPlayer.getInstanc();
+ }
+
+ // 操作分成 4 步
+
+ public void ready() {
+ popcorn.on();
+ popcorn.pop();
+ screen.down();
+ projector.on();
+ stereo.on();
+ dVDPlayer.on();
+ theaterLight.dim();
+ }
+
+ public void play() {
+ dVDPlayer.play();
+ }
+
+ public void pause() {
+ dVDPlayer.pause();
+ }
+
+ public void end() {
+ popcorn.off();
+ theaterLight.bright();
+ screen.up();
+ projector.off();
+ stereo.off();
+ dVDPlayer.off();
+ }
+}
+```
+
+
+
+```java
+public class Client {
+
+ public static void main(String[] args) {
+ // TODO Auto-generated method stub
+ // 这里直接调用。。 很麻烦
+ HomeTheaterFacade homeTheaterFacade = new HomeTheaterFacade();
+ homeTheaterFacade.ready();
+ homeTheaterFacade.play();
+
+ homeTheaterFacade.end();
+ }
+}
+```
+
+## 门面模式的应用场景举例
+
+1. 在 GoF 给出的定义中提到，“门面模式让子系统更加易用”，实际上，它除了解决易用性问题之外，还能解决其他很多方面的问题。关于这一点，我总结罗列了 3 个常用的应用场景，你可以参考一下，举一反三地借鉴到自己的项目中。
+2. 除此之外，我还要强调一下，门面模式定义中的“子系统（subsystem）”也可以有多种理解方式。它既可以是一个完整的系统，也可以是更细粒度的类或者模块。关于这一点，在下面的讲解中也会有体现。
+
+
+
+### 解决易用性问题
+
+1. 门面模式可以用来封装系统的底层实现，隐藏系统的复杂性，提供一组更加简单易用、更高层的接口。比如，Linux 系统调用函数就可以看作一种“门面”。它是 Linux 操作系统暴露给开发者的一组“特殊”的编程接口，它封装了底层更基础的 Linux 内核调用。再比如，Linux 的 Shell 命令，实际上也可以看作一种门面模式的应用。它继续封装系统调用，提供更加友好、简单的命令，让我们可以直接通过执行命令来跟操作系统交互。
+2. 我们前面也多次讲过，设计原则、思想、模式很多都是相通的，是同一个道理不同角度的表述。实际上，从隐藏实现复杂性，提供更易用接口这个意图来看，门面模式有点类似之前讲到的迪米特法则（最少知识原则）和接口隔离原则：两个有交互的系统，只暴露有限的必要的接口。除此之外，门面模式还有点类似之前提到封装、抽象的设计思想，提供更抽象的接口，封装底层实现细节。
+
+
+
+
+
+### 解决性能问题
+
+1. 关于利用门面模式解决性能问题这一点，刚刚我们已经讲过了。我们通过将多个接口调用替换为一个门面接口调用，减少网络通信成本，提高 App 客户端的响应速度。所以，关于这点，我就不再举例说明了。我们来讨论一下这样一个问题：从代码实现的角度来看，该如何组织门面接口和非门面接口？
+2. 如果门面接口不多，我们完全可以将它跟非门面接口放到一块，也不需要特殊标记，当作普通接口来用即可。如果门面接口很多，我们可以在已有的接口之上，再重新抽象出一层，专门放置门面接口，从类、包的命名上跟原来的接口层做区分。如果门面接口特别多，并且很多都是跨多个子系统的，我们可以将门面接口放到一个新的子系统中。
+
+
+
+### 解决分布式事务问题
+
+1. 关于利用门面模式来解决分布式事务问题，我们通过一个例子来解释一下。
+2. 在一个金融系统中，有两个业务领域模型，用户和钱包。这两个业务领域模型都对外暴露了一系列接口，比如用户的增删改查接口、钱包的增删改查接口。假设有这样一个业务场景：在用户注册的时候，我们不仅会创建用户（在数据库 User 表中），还会给用户创建一个钱包（在数据库的 Wallet 表中）。
+3. 对于这样一个简单的业务需求，我们可以通过依次调用用户的创建接口和钱包的创建接口来完成。但是，用户注册需要支持事务，也就是说，创建用户和钱包的两个操作，要么都成功，要么都失败，不能一个成功、一个失败。
+4. 要支持两个接口调用在一个事务中执行，是比较难实现的，这涉及分布式事务问题。虽然我们可以通过引入分布式事务框架或者事后补偿的机制来解决，但代码实现都比较复杂。而最简单的解决方案是，利用数据库事务或者 Spring 框架提供的事务（如果是 Java 语言的话），在一个事务中，执行创建用户和创建钱包这两个 SQL 操作。这就要求两个 SQL 操作要在一个接口中完成，所以，我们可以借鉴门面模式的思想，再设计一个包裹这两个操作的新接口，让新接口在一个事务中执行两个 SQL 操作。
+
+
+
+# 组合模式【不常用】
+
+1. 组合模式跟我们之前讲的面向对象设计中的“组合关系（通过组合来组装两个类）”，完全是两码事。这里讲的“组合模式”，主要是用来处理树形结构数据。这里的“数据”，你可以简单理解为一组对象集合，待会我们会详细讲解。
+2. 正因为其应用场景的特殊性，数据必须能表示成树形结构，这也导致了这种模式在实际的项目开发中并不那么常用。但是，一旦数据满足树形结构，应用这种模式就能发挥很大的作用，能让代码变得非常简洁。
+
+
+
+
+
+## 组合模式的原理与实现
+
+1. 在 GoF 的《设计模式》一书中，组合模式是这样定义的：
+
+> Compose objects into tree structure to represent part-whole hierarchies.Composite lets client treat individual objects and compositions of objects uniformly.
+
+2. 翻译成中文就是：将一组对象组织（Compose）成树形结构，以表示一种“部分 - 整体”的层次结构。组合让客户端（在很多设计模式书籍中，“客户端”代指代码的使用者。）可以统一单个对象和组合对象的处理逻辑。接下来，对于组合模式，我举个例子来给你解释一下。
+
+3. 假设我们有这样一个需求：设计一个类来表示文件系统中的目录，能方便地实现下面这些功能：
+
+- 动态地添加、删除某个目录下的子目录或文件；
+
+- 统计指定目录下的文件个数；
+
+- 统计指定目录下的文件总大小。
+
+4. 我这里给出了这个类的骨架代码，如下所示。其中的核心逻辑并未实现，你可以试着自己去补充完整，再来看我的讲解。在下面的代码实现中，我们把文件和目录统一用 FileSystemNode 类来表示，并且通过 isFile 属性来区分。
+
+
+
+```java
+public class FileSystemNode {
+ private String path;
+ private boolean isFile;
+ private List/wz/ + * + *
/wz/a.txt + * + *
/wz/b.txt + * + *
/wz/movies/ + * + *
/wz/movies/c.avi + * + *
/xzg/ + * + *
/xzg/docs/ + * + *
/xzg/docs/d.txt
+ */
+ Directory fileSystemTree = new Directory("/");
+ Directory node_wz = new Directory("/wz/");
+ Directory node_xzg = new Directory("/xzg/");
+ fileSystemTree.addSubNode(node_wz);
+ fileSystemTree.addSubNode(node_xzg);
+
+
+ File node_wz_a = new File("/wz/a.txt");
+ File node_wz_b = new File("/wz/b.txt");
+ Directory node_wz_movies = new Directory("/wz/movies/");
+ node_wz.addSubNode(node_wz_a);
+ node_wz.addSubNode(node_wz_b);
+ node_wz.addSubNode(node_wz_movies);
+
+
+ File node_wz_movies_c = new File("/wz/movies/c.avi");
+ node_wz_movies.addSubNode(node_wz_movies_c);
+
+
+ Directory node_xzg_docs = new Directory("/xzg/docs/");
+ node_xzg.addSubNode(node_xzg_docs);
+
+
+ File node_xzg_docs_d = new File("/xzg/docs/d.txt");
+ node_xzg_docs.addSubNode(node_xzg_docs_d);
+
+
+ System.out.println("/ files num:" + fileSystemTree.countNumOfFiles());
+ System.out.println("/wz/ files num:" + node_wz.countNumOfFiles());
+ }
+}
+
+```
+
+1. 我们对照着这个例子，再重新看一下组合模式的定义：“将一组对象（文件和目录）组织成树形结构，以表示一种‘部分 - 整体’的层次结构（目录与子目录的嵌套结构）。组合模式让客户端可以统一单个对象（文件）和组合对象（目录）的处理逻辑（递归遍历）。”
+2. 实际上，刚才讲的这种组合模式的设计思路，与其说是一种设计模式，倒不如说是对业务场景的一种数据结构和算法的抽象。其中，数据可以表示成树这种数据结构，业务需求可以通过在树上的递归遍历算法来实现。
+
+
+
+## 组合模式的应用场景举例
+
+1. 刚刚我们讲了文件系统的例子，对于组合模式，我这里再举一个例子。搞懂了这两个例子，你基本上就算掌握了组合模式。在实际的项目中，遇到类似的可以表示成树形结构的业务场景，你只要“照葫芦画瓢”去设计就可以了。
+2. 假设我们在开发一个 OA 系统（办公自动化系统）。公司的组织结构包含部门和员工两种数据类型。其中，部门又可以包含子部门和员工。在数据库中的表结构如下所示：
+
+
+
+
+
+
+
+1. 我们希望在内存中构建整个公司的人员架构图（部门、子部门、员工的隶属关系），并且提供接口计算出部门的薪资成本（隶属于这个部门的所有员工的薪资和）。
+2. 部门包含子部门和员工，这是一种嵌套结构，可以表示成树这种数据结构。计算每个部门的薪资开支这样一个需求，也可以通过在树上的遍历算法来实现。所以，从这个角度来看，这个应用场景可以使用组合模式来设计和实现。
+3. 这个例子的代码结构跟上一个例子的很相似，代码实现我直接贴在了下面，你可以对比着看一下。其中，HumanResource 是部门类（Department）和员工类（Employee）抽象出来的父类，为的是能统一薪资的处理逻辑。Demo 中的代码负责从数据库中读取数据并在内存中构建组织架构图。
+
+```java
+public abstract class HumanResource {
+ protected long id;
+ protected double salary;
+
+ public HumanResource(long id) {
+ this.id = id;
+ }
+
+ public long getId() {
+ return id;
+ }
+
+ public abstract double calculateSalary();
+
+}
+
+public class Employee extends HumanResource {
+
+ public Employee(long id, double salary) {
+ super(id);
+ this.salary = salary;
+ }
+
+ @Override
+
+ public double calculateSalary() {
+ return salary;
+ }
+}
+
+public class Department extends HumanResource {
+ private List