修改 Builder 模式 README.md

JamesZBL · JamesZBL · commit 927962aa2feb · 2017-11-12T00:06:18.000+08:00
diff --git a/README.md b/README.md
@@ -18,3 +18,9 @@
 保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的
 一块块砖石一样。项目中合理地运用设计模式可以完美地解决很多问题，每种模式在现实中都有相应的原理来与之对应，每种模式都描述了一个在我们
 周围不断重复发生的问题，以及该问题的核心解决方案，这也是设计模式能被广泛应用的原因。
+
+## 目录
+
+### 构建型模式
+
+> [Builder (创建者)](https://github.com/JamesZBL/java_design_patterns/tree/develop/builder) 
diff --git a/builder/README.md b/builder/README.md
@@ -2,18 +2,18 @@
 
 ## 用途
 
-将一个复杂对象的构造与它分开，使得同样的构造过程可以产生不同的对象。
+> 将一个复杂对象的构造与它分开，使得同样的构造过程可以产生不同的对象。
 
 ## 实例
 
-假定需要生成一个虚拟的人物模型，人物主要包括几个简单的属性：姓名、年龄、国籍以及肤色。假如一个数据模型的拥有很多属性，如果单纯使用构造方法来实例化对象，势必会造成构造方法参数爆炸的问题，也可以称之为“反可伸缩构造方法模式”。代码的可读性和可靠性大大降低。此时，可以为这个对象创建的过程指定一个创建者，我们只需要向创建者描述该对象的一些具体细节，接下来的构造过程就统统交给创建者完成了。
+> 假定需要生成一个虚拟的人物模型，人物主要包括几个简单的属性：姓名、年龄、国籍以及肤色。假如一个数据模型的拥有很多属性，如果单纯使用构造方法来实例化对象，势必会造成构造方法参数爆炸的问题，也可以称之为“反可伸缩构造方法模式”。代码的可读性和可靠性大大降低。此时，可以为这个对象创建的过程指定一个创建者，我们只需要向创建者描述该对象的一些具体细节，接下来的构造过程就统统交给创建者完成了。
 
-一下是“反可伸缩构造方法模式”的一个实例：
+> 以下是“反可伸缩构造方法模式”的一个实例：
 
 ```
 public Person(String name,Integer age,Nationality nationality,SkinColor skinColor...){...}
 ```
-如果一直这样下去，随着属性的增多，构造方法的参数的数量也会变得越来越多，对于开发人员是非常头疼的。对属性的更改使得构造方法的维护难度增加了不少，这就是所谓的“反可伸缩构造方法模式”。
+> 如果一直这样下去，随着属性的增多，构造方法的参数的数量也会变得越来越多，对于开发人员是非常头疼的。对属性的更改使得构造方法的维护难度增加了不少，这就是所谓的“反可伸缩构造方法模式”。
 
 ## 模式分析
 
