markdown格式修正

src/dp/com/company/adapter/README.md

@@ -1,27 +1,27 @@
-#适配器模式(Adapter Pattern)
-定义：Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.（将一个类的接口变换成客户端所期待的另一种接口，从而是原本因接口不匹配而无法在一起工作的两个类能够在一起工作。）  
-
-
-适配器模式通用类图如图所示。  
-![Alt text](adapter.jpg "适配器模式类图")
-
-
- 我们先来看看适配器模式的三个角色：
-
-- Target目标角色：该角色定义把其它类转换为何种接口，也就是我们的期望接口。
-- Adaptee源角色：你想把谁转换成目标角色。
-- Adapter适配器角色：适配器模式的核心角色，其它两个角色都是已经存在的角色，而适配器角色是需要新建立的，它的职责非常简单，把源角色转换成目标角色，怎么转换?通过继承或类关联的方式。
-
-
-#适配器模式的应用
-##适配器模式的优点
- * 适配器模式可以让两个没有任何关系得类在一起运行，只要适配器这个角色能够搞定他就成。
- * 增加了类的透明性。我们访问的Target目标角色，但是具体的实现都委托给了源角色，而这些对高层次模块时透明的，也是它不需要关心的。
- * 提高了类的复用度。
- * 灵活性非常好
-
-##适配器模式的使用场景
- 适配器应用的场景只要记住一点就足够了：你有动机修改了一个已经投产中的接口时，适配器模式可能是最适合你的模式。  
-
-##适配器模式的注意事项 
+# 适配器模式(Adapter Pattern)
+定义：Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.（将一个类的接口变换成客户端所期待的另一种接口，从而是原本因接口不匹配而无法在一起工作的两个类能够在一起工作。）  
+
+
+适配器模式通用类图如图所示。  
+![Alt text](adapter.jpg "适配器模式类图")
+
+
+ 我们先来看看适配器模式的三个角色：
+
+- Target目标角色：该角色定义把其它类转换为何种接口，也就是我们的期望接口。
+- Adaptee源角色：你想把谁转换成目标角色。
+- Adapter适配器角色：适配器模式的核心角色，其它两个角色都是已经存在的角色，而适配器角色是需要新建立的，它的职责非常简单，把源角色转换成目标角色，怎么转换?通过继承或类关联的方式。
+
+
+# 适配器模式的应用
+### 1.适配器模式的优点
+ * 适配器模式可以让两个没有任何关系得类在一起运行，只要适配器这个角色能够搞定他就成。
+ * 增加了类的透明性。我们访问的Target目标角色，但是具体的实现都委托给了源角色，而这些对高层次模块时透明的，也是它不需要关心的。
+ * 提高了类的复用度。
+ * 灵活性非常好
+
+### 2.适配器模式的使用场景
+ 适配器应用的场景只要记住一点就足够了：你有动机修改了一个已经投产中的接口时，适配器模式可能是最适合你的模式。  
+
+### 3.适配器模式的注意事项 
 适配器模式最好在详细设计不要考虑它，它不是为了解决还处在开发阶段的问题，而是解决正在服役的项目问题。 

src/dp/com/company/bridge/README.md

@@ -1,30 +1,30 @@
-#桥梁模式(Bridge Pattern) 
-定义：Decouple an abstraction from its implementation so that the two can vary independently.（将抽象和实现解耦，使得两者可以独立地变化。）  
-
- 桥梁模式的通用类图如图所示。  
-![Alt text](bridge.jpg "桥梁模式类图")
-
-
-- Abstraction抽象化角色：它的主要职责是定义出该角色的行为，同时保存一个对实现化角色的引用，该角色一般是抽象类。
-- Implementor实现化角色：它是接口或者抽象类，定义角色必须的行为和属性。
-- RefinedAbstraction修正抽象化角色：它引用实现化角色对抽象化角色进行修正。
-- ConcreteImplementor具体实现化角色：它实现接口和抽象类定义的方法和属性。
-
-
-桥梁模式的几个名词比较拗口，大家只要记住一句话就成：抽象角色引用实现角色，或者说抽象角色的部分实现是由实现角色完成的。  
-
-
-#桥梁模式的应用
-##1.桥梁模式的优点
- * 抽象和实现分离：它完全是为了解决集成的缺点而提出的设计模式。在该模式下，实现可以不受抽象的约束，不用再绑定在一个固定的抽象层次上。
- * 优秀的扩充能力。
- * 实现细节对客户透明。客户不用关心细节的实现，它已经由抽象层通过聚合关系完成了封装。  
-
-
-##2.桥梁模式的使用场景
- * 不希望或不适合使用集成的场景：例如继承层次过渡、无法更细化设计颗粒等场景，需要考虑使用桥梁模式。
- * 接口或抽象类不稳定的场景：明知道接口不稳定还想通过实现或继承来实现业务需求，那是得不偿失的，也是比较失败得作法。
- * 重用性要求较高的场景：设计的颗粒度越细，则被重用的可能性就越大，而采用继承则受父类的限制，不可能出现太细的颗粒度。
-
-##3.桥梁模式的注意事项
+# 桥梁模式(Bridge Pattern) 
+定义：Decouple an abstraction from its implementation so that the two can vary independently.（将抽象和实现解耦，使得两者可以独立地变化。）  
+
+ 桥梁模式的通用类图如图所示。  
+![Alt text](bridge.jpg "桥梁模式类图")
+
+
+- Abstraction抽象化角色：它的主要职责是定义出该角色的行为，同时保存一个对实现化角色的引用，该角色一般是抽象类。
+- Implementor实现化角色：它是接口或者抽象类，定义角色必须的行为和属性。
+- RefinedAbstraction修正抽象化角色：它引用实现化角色对抽象化角色进行修正。
+- ConcreteImplementor具体实现化角色：它实现接口和抽象类定义的方法和属性。
+
+
+桥梁模式的几个名词比较拗口，大家只要记住一句话就成：抽象角色引用实现角色，或者说抽象角色的部分实现是由实现角色完成的。  
+
+
+# 桥梁模式的应用
+### 1.桥梁模式的优点
+ * 抽象和实现分离：它完全是为了解决集成的缺点而提出的设计模式。在该模式下，实现可以不受抽象的约束，不用再绑定在一个固定的抽象层次上。
+ * 优秀的扩充能力。
+ * 实现细节对客户透明。客户不用关心细节的实现，它已经由抽象层通过聚合关系完成了封装。  
+
+
+### 2.桥梁模式的使用场景
+ * 不希望或不适合使用集成的场景：例如继承层次过渡、无法更细化设计颗粒等场景，需要考虑使用桥梁模式。
+ * 接口或抽象类不稳定的场景：明知道接口不稳定还想通过实现或继承来实现业务需求，那是得不偿失的，也是比较失败得作法。
+ * 重用性要求较高的场景：设计的颗粒度越细，则被重用的可能性就越大，而采用继承则受父类的限制，不可能出现太细的颗粒度。
+
+### 3.桥梁模式的注意事项
  桥梁模式是非常简单的，使用该模式时注意考虑如何拆分抽象和实现，并不是一涉及继承就要考虑使用该模式，那还要继承干什么呢？桥梁模式的意图还是对变化的封装，尽量把可能变化的因素封装到最细、最小的逻辑单元中，避免风险扩散。因此读者在进行系统设计时，发现类的继承有N层时，可以考虑使用桥梁模式。

src/dp/com/company/builder/README.md

@@ -1,36 +1,37 @@
-#建造者模式(Builder Pattern) 
-定义：Separate the construction of a complex object from its representation so that the same construction process can create different representations. 将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。     
-
-建造者模式的通用类图如下图：  
-![Alt text](builder.jpg "建造者模式类图")
-
-在建造者模式中，有如下四个角色：
-
-- Product产品类：通常是实现了模板方法模式，也就是有模板方法和基本方法，这个参考上一章节的模板方法模式。在例子中，BenzModel和BMWModel就属于产品类。
-- Builder抽象建造者：规范产品的组建，一般是由子类实现。在例子中，CarBuilder属于抽象建造者。 
-- ConcreteBuilder具体建造者：实现抽象类定义的所有方法，并且返回一个组件好的对象。在例子中，BenzBuilder和BMWBuilder就属于具体建造者。
-- Director导演：负责安排已有模块的顺序，然后告诉Builder开始建造，在上面的例子中就是我们的老大，牛叉公司找到老大，说我要这个，这个，那个类型的车辆模型，然后老大就把命令传递给我，我和我的团队就开始拼命的建造，于是一个项目建设完毕了。 
-
-#建造者模式的应用
-##建造者模式的优点
- * 封装性。使用建造者模式可以使客户端不必知道产品内部组成的细节，如例子中我们就不需要关心每一个具体的模型内部是如何实现的，产生的对象类型就是CarModel。 
- * 建造者独立，容易扩展。
- * 便于控制细节风险。由于具体的建造者是独立的，因此可以对建造过程逐步细化，而不对其他的模块产生任何影响。 
-
-##建造者模式的使用场景
- * 相同的方法，不同的执行顺序，产生不同的事件结果时，可以采用建造者模式。
- * 多个部件或零件,都可以装配到一个对象中，但是产生的运行结果又不相同时，则可以使用该模式。 
- * 产品类非常复杂，或者产品类中的调用顺序不同产生了不同的效能，这个时候使用建造者模式是非常合适。 
- * 在对象创建过程中会使用到系统中的一些其它对象，这些对象在产品对象的创建过程中不易得到时，也可以采用建造者模式封装该对象的创建过程。该种场景，只能是一个补偿方法，因为一个对象不容易获得，而在设计阶段竟然没有发觉，而要通过创建者模式柔化创建过程，本身已经违反设计最初目标。
-
-##建造者模式的注意事项
-建造者模式关注的是的零件类型和装配工艺（顺序），这是它与工厂方法模式最大不同的地方，虽然同为创建类模式，但是注重点不同。  
-
-#建造者模式的扩展
-已经不用扩展了，因为我们在汽车模型制造的例子中已经对建造者模式进行了扩展，引入了模板方法模式，可能大家会比较疑惑，为什么在其他介绍设计模式的书籍上创建者模式并不是这样说的，读者请注意，建造者模式中还有一个角色没有说明，就是零件，建造者怎么去建造一个对象？是零件的组装，组装顺序不同对象效能也不同，这才是建造者模式要表达的核心意义，而怎么才能更好的达到这种效果呢？引入模板方法模式是一个非常简单而有效的办法。  
-大家看到这里估计就开始犯嘀咕了，这个建造者模式和工厂模式非常相似呀，Yes，是的，是非常相似，但是记住一点你就可以游刃有余的使用了：建造者模式最主要功能是基本方法的调用顺序安排，也就是这些基本方法已经实现了，通俗的说就是零件的装配，顺序不同产生的对象也不同；而工厂方法则重点是创建，创建零件时它的主要职责，你要什么对象我创造一个对象出来，组装顺序则不是他关心的。  
-
-#最佳实践
-再次说明，在使用建造者模式的时候考虑一下模板方法模式，别孤立的思考一个模式，僵化的套用一个模式会让受害无穷！
-
+# 建造者模式(Builder Pattern) 
+定义：Separate the construction of a complex object from its representation so that the same construction process can create different representations. 将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。     
+
+建造者模式的通用类图如下图：  
+![Alt text](builder.jpg "建造者模式类图")
+
+在建造者模式中，有如下四个角色：
+
+- Product产品类：通常是实现了模板方法模式，也就是有模板方法和基本方法，这个参考上一章节的模板方法模式。在例子中，BenzModel和BMWModel就属于产品类。
+- Builder抽象建造者：规范产品的组建，一般是由子类实现。在例子中，CarBuilder属于抽象建造者。 
+- ConcreteBuilder具体建造者：实现抽象类定义的所有方法，并且返回一个组件好的对象。在例子中，BenzBuilder和BMWBuilder就属于具体建造者。
+- Director导演：负责安排已有模块的顺序，然后告诉Builder开始建造，在上面的例子中就是我们的老大，牛叉公司找到老大，说我要这个，这个，那个类型的车辆模型，然后老大就把命令传递给我，我和我的团队就开始拼命的建造，于是一个项目建设完毕了。 
+
+# 建造者模式的应用
+### 1.建造者模式的优点
+ * 封装性。使用建造者模式可以使客户端不必知道产品内部组成的细节，如例子中我们就不需要关心每一个具体的模型内部是如何实现的，产生的对象类型就是CarModel。 
+ * 建造者独立，容易扩展。
+ * 便于控制细节风险。由于具体的建造者是独立的，因此可以对建造过程逐步细化，而不对其他的模块产生任何影响。 
+
+### 2.建造者模式的使用场景
+ * 相同的方法，不同的执行顺序，产生不同的事件结果时，可以采用建造者模式。
+ * 多个部件或零件,都可以装配到一个对象中，但是产生的运行结果又不相同时，则可以使用该模式。 
+ * 产品类非常复杂，或者产品类中的调用顺序不同产生了不同的效能，这个时候使用建造者模式是非常合适。 
+ * 在对象创建过程中会使用到系统中的一些其它对象，这些对象在产品对象的创建过程中不易得到时，也可以采用建造者模式封装该对象的创建过程。该种场景，只能是一个补偿方法，因为一个对象不容易获得，而在设计阶段竟然没有发觉，而要通过创建者模式柔化创建过程，本身已经违反设计最初目标。
+
+### 3.建造者模式的注意事项
+建造者模式关注的是的零件类型和装配工艺（顺序），这是它与工厂方法模式最大不同的地方，虽然同为创建类模式，但是注重点不同。  
+
+# 建造者模式的扩展
+已经不用扩展了，因为我们在汽车模型制造的例子中已经对建造者模式进行了扩展，引入了模板方法模式，可能大家会比较疑惑，为什么在其他介绍设计模式的书籍上创建者模式并不是这样说的，读者请注意，建造者模式中还有一个角色没有说明，就是零件，建造者怎么去建造一个对象？是零件的组装，组装顺序不同对象效能也不同，这才是建造者模式要表达的核心意义，而怎么才能更好的达到这种效果呢？引入模板方法模式是一个非常简单而有效的办法。  
+
+大家看到这里估计就开始犯嘀咕了，这个建造者模式和工厂模式非常相似呀，Yes，是的，是非常相似，但是记住一点你就可以游刃有余的使用了：建造者模式最主要功能是基本方法的调用顺序安排，也就是这些基本方法已经实现了，通俗的说就是零件的装配，顺序不同产生的对象也不同；而工厂方法则重点是创建，创建零件时它的主要职责，你要什么对象我创造一个对象出来，组装顺序则不是他关心的。  
+
+# 最佳实践
+再次说明，在使用建造者模式的时候考虑一下模板方法模式，别孤立的思考一个模式，僵化的套用一个模式会让受害无穷！
+
         

src/dp/com/company/chain_of_responsibility/README.md

@@ -1,18 +1,18 @@
-#责任链模式 (Command Pattern) 
-定义：Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.（使多个对象都有机会处理请求，从而避免了请求的发送者接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递请求，直到有对象处理它为止。）  
-
-
-责任链模式的通用类图如下图：  
-![Alt text](chainofresponsibility.jpg "责任链模式类图")
-
-#责任链模式的应用
-##1.责任链模式的优点
-责任链模式非常显著的优点是将请求和处理分开。请求者可以不用知道谁处理的，处理者可以不用知道请求的全貌，两者解耦，提高系统的灵活性。  
-
-
-##2.责任链模式的缺点 
-责任链模式有两个非常显著的缺点：一是性能问题，每个请求都是从链头到链尾，特别是在链比较长的时候，性能是一个非常大的问题。而是调试不很方便，特别是链条比较长，环节比较多的时候，由于采用了类似递归的方式，调试的时候逻辑可能比较复杂。  
-
-
-##3.责任链模式的注意事项
+# 责任链模式 (Command Pattern) 
+定义：Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.（使多个对象都有机会处理请求，从而避免了请求的发送者接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递请求，直到有对象处理它为止。）  
+
+
+责任链模式的通用类图如下图：  
+![Alt text](chainofresponsibility.jpg "责任链模式类图")
+
+# 责任链模式的应用
+### 1.责任链模式的优点
+责任链模式非常显著的优点是将请求和处理分开。请求者可以不用知道谁处理的，处理者可以不用知道请求的全貌，两者解耦，提高系统的灵活性。  
+
+
+### 2.责任链模式的缺点 
+责任链模式有两个非常显著的缺点：一是性能问题，每个请求都是从链头到链尾，特别是在链比较长的时候，性能是一个非常大的问题。二是调试不很方便，特别是链条比较长，环节比较多的时候，由于采用了类似递归的方式，调试的时候逻辑可能比较复杂。  
+
+
+### 3.责任链模式的注意事项
 链中节点数量需要控制，避免出现超长链的情况，一般的做法是在Handler中设置一个最大节点数量，在SetNext方法中判断是否是否是超过其阀值，超过则不允许该链建立，避免无意识地破坏系统性能。