更新设计模式内容

_sidebar.md

@@ -1,10 +1 @@
-* [灵魂拷问](/doc/honor.md "软件开发规约")
-* [领域模型](/doc/ddd.md "软件开发规约")
-* [SOLID  规则](/doc/solid.md "soild设计规则")
-* [设计模式之美](/doc/design/README.md "设计模式之美")
-    * [1.1工厂模式](/doc/design/1.1factory.md "设计模式之美")
-    * [1.2抽象工厂模式](/doc/design/1.2abstract-factory.md "设计模式之美")
-    * [1.3单例模式](/doc/design/1.3singleton-pattern.md "单例模式")
-    * [1.4建造者模式](/doc/design/1.4builder-pattern.md "建造者模式")
-    * [1.5原型模式](/doc/design/1.5prototype-pattern.md "原型模式")
-    * [2.1适配器模式](/doc/design/2.1adapter-pattern.md "原型模式")
+* [灵魂拷问](/honor.md "软件开发规约")

doc/README.md

@@ -0,0 +1,13 @@
+## 简介
+> 设计模式相关汇集，记录学习以及备用。
+## 目标
+?> 所有的设计都源于理论知识的支撑,没有理论支撑则如空中楼阁！
+
+## DRY原则 
+
+!> Don’t Repeat Yourself. 不要重复你自己.DRY代表“不要重复自己”，这是软件开发的一个基本原则，目的是减少信息的重复。干原理是这样表述的:“每一个知识或逻辑必须在一个系统中有一个单一的、明确的表示。”
+
+## KISS原则
+
+!> Keep It Simple, Stupid. 保持简单，愚蠢 .
+指产品的设计越简单越好，任何没有必要的复杂都是需要避免的。其最完美的案例是傻瓜相机，傻瓜相机操作简单，似乎连傻瓜都能利用它拍摄出曝光准确、影像清晰的照片来

doc/_sidebar.md

@@ -0,0 +1,12 @@
+* [领域模型](/doc/ddd.md "软件开发规约")
+* [SOLID  规则](/doc/solid.md "soild设计规则")
+* [设计模式之美](/doc/design/README.md "设计模式之美")
+    * [1.1工厂模式](/doc/design/1.1factory.md "设计模式之美")
+    * [1.2抽象工厂模式](/doc/design/1.2abstract-factory.md "设计模式之美")
+    * [1.3单例模式](/doc/design/1.3singleton-pattern.md "单例模式")
+    * [1.4建造者模式](/doc/design/1.4builder-pattern.md "建造者模式")
+    * [1.5原型模式](/doc/design/1.5prototype-pattern.md "prototype")
+    * [2.1适配器模式](/doc/design/2.1adapter-pattern.md "adepter")
+    * [2.2桥接模式](/doc/design/2.2bridge.md "bridge")
+    * [2.3过滤器模式](/doc/design/2.3filter.md "filter")
+    * [2.4组合模式](/doc/design/2.4composite.md "composite")

doc/ddd.md

@@ -28,6 +28,7 @@ Eric认为需要和领域专家良好地合作，从交谈中发现通用语言
 <figure class="thumbnails">
     <img src="assets/img/ddd/compare.jpg"  alt="Screenshot of coverpage" title="Cover page">
     <img src="assets/img/ddd/domain.jpg"  alt="Screenshot of coverpage" title="Cover page">
+    <img src="assets/img/ddd/design.jpg"  alt="Screenshot of coverpage" title="Cover page">
 </figure>
 
 ## 战略设计

doc/design/1.2abstract-factory.md

@@ -0,0 +1,139 @@
+### 抽象工厂模式  <!-- {docsify-ignore-all} -->
+[抽象工厂模式](https://www.runoob.com/design-pattern/abstract-factory-pattern.html ':crossorgin')
+
+?> &emsp;&emsp;抽象工厂模式（Abstract Factory Pattern）是围绕一个超级工厂创建其他工厂。该超级工厂又称为其他工厂的工厂。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。
+ 在抽象工厂模式中，接口是负责创建一个相关对象的工厂，不需要显式指定它们的类。每个生成的工厂都能按照工厂模式提供对象。
+#### 简介
+*****
+- **意图：** 提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
+- **主要解决：** 主要解决接口选择的问题。
+- **何时使用：** 系统的产品有多于一个的产品族，而系统只消费其中某一族的产品。
+- **如何解决：** 在一个产品族里面，定义多个产品。
+- **关键代码：** 在一个工厂里聚合多个同类产品。
+- **应用实例：** 工作了，为了参加一些聚会，肯定有两套或多套衣服吧，比如说有商务装（成套，一系列具体产品）、时尚装（成套，一系列具体产品），甚至对于一个家庭来说，可能有商务女装、商务男装、时尚女装、时尚男装，这些也都是成套的，即一系列具体产品。假设一种情况（现实中是不存在的，要不然，没法进入共产主义了，但有利于说明抽象工厂模式），在您的家中，某一个衣柜（具体工厂）只能存放某一种这样的衣服（成套，一系列具体产品），每次拿这种成套的衣服时也自然要从这个衣柜中取出了。用 OOP 的思想去理解，所有的衣柜（具体工厂）都是衣柜类的（抽象工厂）某一个，而每一件成套的衣服又包括具体的上衣（某一具体产品），裤子（某一具体产品），这些具体的上衣其实也都是上衣（抽象产品），具体的裤子也都是裤子（另一个抽象产品）。
+- **优点：** 当一个产品族中的多个对象被设计成一起工作时，它能保证客户端始终只使用同一个产品族中的对象。
+- **缺点：** 产品族扩展非常困难，要增加一个系列的某一产品，既要在抽象的 Creator 里加代码，又要在具体的里面加代码。
+- **使用场景：**  1、QQ 换皮肤，一整套一起换。 2、生成不同操作系统的程序。
+- **注意事项：** 产品族难扩展，产品等级易扩展。
+*****
+
+<figure class="thumbnails">
+    <img src="assets/img/design/abstract-factory.jpg" style="width: 834px;height: 538px;" alt="Screenshot of content" title="Content">
+</figure>
+
+*****
+#### 创建形状和颜色接口类
+```text
+public interface Shape {
+   void draw();
+}
+----------------------------------------
+public interface Color {
+   void fill();
+}
+```
+
+#### 实体创建
+```text
+public class Rectangle implements Shape {
+ 
+   @Override
+   public void draw() {
+      System.out.println("Inside Rectangle::draw() method.");
+   }
+}
+
+public class Square implements Shape {
+ 
+   @Override
+   public void draw() {
+      System.out.println("Inside Square::draw() method.");
+   }
+}
+---------------------------------------------------------
+public class Red implements Color {
+ 
+   @Override
+   public void fill() {
+      System.out.println("Inside Red::fill() method.");
+   }
+}
+
+public class Green implements Color {
+ 
+   @Override
+   public void fill() {
+      System.out.println("Inside Green::fill() method.");
+   }
+}
+```
+#### 抽象工厂构建及实现
+```text
+public abstract class AbstractFactory {
+   public abstract Color getColor(String color);
+   public abstract Shape getShape(String shape) ;
+}
+-------------------------------------------------
+public class ShapeFactory extends AbstractFactory {
+    
+   @Override
+   public Shape getShape(String shapeType){
+      if(shapeType == null){
+         return null;
+      }        
+      if(shapeType.equalsIgnoreCase("CIRCLE")){
+         return new Circle();
+      } else if(shapeType.equalsIgnoreCase("RECTANGLE")){
+         return new Rectangle();
+      } else if(shapeType.equalsIgnoreCase("SQUARE")){
+         return new Square();
+      }
+      return null;
+   }
+   
+   @Override
+   public Color getColor(String color) {
+      return null;
+   }
+}
+---------------------------------------------------
+public class ColorFactory extends AbstractFactory {
+    
+   @Override
+   public Shape getShape(String shapeType){
+      return null;
+   }
+   
+   @Override
+   public Color getColor(String color) {
+      if(color == null){
+         return null;
+      }        
+      if(color.equalsIgnoreCase("RED")){
+         return new Red();
+      } else if(color.equalsIgnoreCase("GREEN")){
+         return new Green();
+      } else if(color.equalsIgnoreCase("BLUE")){
+         return new Blue();
+      }
+      return null;
+   }
+}
+```
+#### 工厂生成类构建
+```text
+public class FactoryProducer {
+   public static AbstractFactory getFactory(String choice){
+      if(choice.equalsIgnoreCase("SHAPE")){
+         return new ShapeFactory();
+      } else if(choice.equalsIgnoreCase("COLOR")){
+         return new ColorFactory();
+      }
+      return null;
+   }
+}
+```
+
+#### 发布npm包
+
+npm publish --registry=http://localhost:8081/repository/casic-npm/

doc/design/2.1adapter-pattern.md

@@ -8,14 +8,31 @@
 *****
 - **意图：** 将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
 - **主要解决：** 主要解决在软件系统中，常常要将一些"现存的对象"放到新的环境中，而新环境要求的接口是现对象不能满足的。
-- **何时使用：**  1、系统需要使用现有的类，而此类的接口不符合系统的需要。 2、想要建立一个可以重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作，这些源类不一定有一致的接口。 3、通过接口转换，将一个类插入另一个类系中。（比如老虎和飞禽，现在多了一个飞虎，在不增加实体的需求下，增加一个适配器，在里面包容一个虎对象，实现飞的接口。）
+- **何时使用：**
+
+?> 1、系统需要使用现有的类，而此类的接口不符合系统的需要。              
+    2、想要建立一个可以重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作，这些源类不一定有一致的接口。               
+    3、通过接口转换，将一个类插入另一个类系中。（比如老虎和飞禽，现在多了一个飞虎，在不增加实体的需求下，增加一个适配器，在里面包容一个虎对象，实现飞的接口。）
 - **如何解决：** 继承或依赖（推荐）。
 - **关键代码：** 适配器继承或依赖已有的对象，实现想要的目标接口。
-- **应用实例：**  1、美国电器 110V，中国 220V，就要有一个适配器将 110V 转化为 220V。 2、JAVA JDK 1.1 提供了 Enumeration 接口，而在 1.2 中提供了 Iterator 接口，想要使用 1.2 的 JDK，则要将以前系统的 Enumeration 接口转化为 Iterator 接口，这时就需要适配器模式。 3、在 LINUX 上运行 WINDOWS 程序。 4、JAVA 中的 jdbc。
-- **优点：**  1、可以让任何两个没有关联的类一起运行。 2、提高了类的复用。 3、增加了类的透明度。 4、灵活性好
+- **应用实例：**
+
+?> 1、 美国电器 110V，中国 220V，就要有一个适配器将 110V 转化为 220V。        
+2、 JAVA JDK 1.1 提供了 Enumeration 接口，而在 1.2 中提供了 Iterator 接口，想要使用 1.2 的 JDK，则要将以前系统的 Enumeration 接口转化为 Iterator 接口，这时就需要适配器模式。 3、在 LINUX 上运行 WINDOWS 程序。 4、JAVA 中的 jdbc。
+
+- **优点：**
+
+?> 1、可以让任何两个没有关联的类一起运行。     
+ 2、提高了类的复用。         
+ 3、增加了类的透明度。        
+ 4、灵活性好
 - **缺点：**  1、过多地使用适配器，会让系统非常零乱，不易整体进行把握。比如，明明看到调用的是 A 接口，其实内部被适配成了 B 接口的实现，一个系统如果太多出现这种情况，无异于一场灾难。因此如果不是很有必要，可以不使用适配器，而是直接对系统进行重构。 2.由于 JAVA 至多继承一个类，所以至多只能适配一个适配者类，而且目标类必须是抽象类。
-- **使用场景：** 有动机地修改一个正常运行的系统的接口，这时应该考虑使用适配器模式。
-- **注意事项：** 适配器不是在详细设计时添加的，而是解决正在服役的项目的问题。
+- **使用场景：** 有动机地修改一个正常运行的系统的接口，这时应该考虑使用适配器模式。<font color=red>多个组件功能类似，但接口不统一且可能会经常切换时，可使用适配器模式</font>
+- **注意事项：** 适配器不是在详细设计时添加的，而是解决正在服役的项目的问题。 
 *****
 
+!> 适配接口及适配接口实现类,实现类进行适配器构建。 
 
+<figure class="thumbnails">
+    <img src="assets/img/design/adepter.png" style="width: 834px;height: 538px;" alt="Screenshot of content" title="Content">
+</figure>

doc/design/2.2bridge.md

@@ -0,0 +1,91 @@
+### 桥接模式  <!-- {docsify-ignore-all} -->
+[桥接模式](https://www.runoob.com/design-pattern/bridge-pattern.html ':crossorgin')
+
+?> &emsp;&emsp;桥接（Bridge）是用于把抽象化与实现化解耦，使得二者可以独立变化。这种类型的设计模式属于结构型模式，它通过提供抽象化和实现化之间的桥接结构，来实现二者的解耦。
+这种模式涉及到一个作为桥接的接口，使得实体类的功能独立于接口实现类。这两种类型的类可被结构化改变而互不影响。
+我们通过下面的实例来演示桥接模式（Bridge Pattern）的用法。其中，可以使用相同的抽象类方法但是不同的桥接实现类，来画出不同颜色的圆。
+#### 简介
+*****
+
+**意图：** 将抽象部分与实现部分分离，使它们都可以独立的变化。       
+**主要解决：** 在有多种可能会变化的情况下，用继承会造成类爆炸问题，扩展起来不灵活。        
+**何时使用：** 实现系统可能有多个角度分类，每一种角度都可能变化。     
+**如何解决：** 把这种多角度分类分离出来，让它们独立变化，减少它们之间耦合。        
+**关键代码：** 抽象类依赖实现类。     
+**应用实例：**  1、猪八戒从天蓬元帅转世投胎到猪，转世投胎的机制将尘世划分为两个等级，即：灵魂和肉体，前者相当于抽象化，后者相当于实现化。生灵通过功能的委派，调用肉体对象的功能，使得生灵可以动态地选择。 2、墙上的开关，可以看到的开关是抽象的，不用管里面具体怎么实现的。            
+**优点：**  1、抽象和实现的分离。 2、优秀的扩展能力。 3、实现细节对客户透明。        
+**缺点：** 桥接模式的引入会增加系统的理解与设计难度，由于聚合关联关系建立在抽象层，要求开发者针对抽象进行设计与编程。              
+**使用场景：**  1、如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的继承联系，通过桥接模式可以使它们在抽象层建立一个关联关系。 2、对于那些不希望使用继承或因为多层次继承导致系统类的个数急剧增加的系统，桥接模式尤为适用。 3、一个类存在两个独立变化的维度，且这两个维度都需要进行扩展。       
+**注意事项：** 对于两个独立变化的维度，使用桥接模式再适合不过了。     
+
+*****
+<figure class="thumbnails">
+    <img src="assets/img/design/bridge.svg" alt="Screenshot of content" title="Content">
+</figure>
+
+*****
+- **步骤 1**   
+
+!> 创建Shape接口
+```text
+public interface Shape {
+   void draw();
+}
+```
+
+- **步骤 2**
+
+!> 实现接口类   
+```text
+public class Rectangle implements Shape {
+ 
+   @Override
+   public void draw() {
+      System.out.println("Inside Rectangle::draw() method.");
+   }
+}
+```
+```text
+public class Square implements Shape {
+ 
+   @Override
+   public void draw() {
+      System.out.println("Inside Square::draw() method.");
+   }
+}
+```
+```text
+public class Circle implements Shape {
+ 
+   @Override
+   public void draw() {
+      System.out.println("Inside Circle::draw() method.");
+   }
+}
+```
+- **步骤 3**
+
+!> 创建工厂 
+```text
+public class ShapeFactory {
+    
+   //使用 getShape 方法获取形状类型的对象
+   public Shape getShape(String shapeType){
+      if(shapeType == null){
+         return null;
+      }        
+      if(shapeType.equalsIgnoreCase("CIRCLE")){
+         return new Circle();
+      } else if(shapeType.equalsIgnoreCase("RECTANGLE")){
+         return new Rectangle();
+      } else if(shapeType.equalsIgnoreCase("SQUARE")){
+         return new Square();
+      }
+      return null;
+   }
+}
+```
+
+- **步骤 4**
+
+?> 使用工厂创建实例

doc/design/2.3filter.md

@@ -0,0 +1,11 @@
+### 过滤器模式  <!-- {docsify-ignore-all} -->
+[过滤器模式](https://www.runoob.com/design-pattern/filter-pattern.html ':crossorgin')
+
+?> &emsp;&emsp;过滤器模式（Filter Pattern）或标准模式（Criteria Pattern）是一种设计模式，这种模式允许开发人员使用不同的标准来过滤一组对象，通过逻辑运算以解耦的方式把它们连接起来。这种类型的设计模式属于结构型模式，它结合多个标准来获得单一标准。
+#### 简介
+*****
+我们将创建一个 Person 对象、Criteria 接口和实现了该接口的实体类，来过滤 Person 对象的列表。CriteriaPatternDemo 类使用 Criteria 对象，基于各种标准和它们的结合来过滤 Person 对象的列表。
+*****
+<figure class="thumbnails">
+    <img src="assets/img/design/filter.svg" alt="Screenshot of content" title="Content">
+</figure>