设计模式开篇：为什么要使用设计模式？
为何要使用设计模式
设计模式，正如它的名字一样——设计。简单的理解，设计并不是必要的，像装修房子一样，如果我们可以完全不考虑水电安装以及家具的摆放，例如卫生间不安装水管；衣柜放厨房，这样房子也是可以居住的，那为什么要有设计呢？因为我们可以通过设计，例如床边安装插座；洗衣机放阳台，来达到房子的最高舒适程度。Java设计模式，同样也是为了达到这样一个效果，使java代码变得更加简洁与灵活，通常我们在判断一个一段代码的好与坏都会用到一个名词——“高内聚，低耦合”，即每个模块分工明确，模块与模块之间的关联比较开放，即“模块内部关系紧密，一个模块只做一件事；模块外部依赖灵活，每个模块直接干涉较小”这种关系的程序，作为一个有追求的开发者，我想他应该是没有理由去拒绝设计模式的。
Java中常用的设计模式有23种，但是已知的设计模式至少已经超过了100种，这23种设计模式可能不是最优的，但也可以称得上是名列前茅，很多时候我们在使用了这些模式后却不知道，到头来就会发出惊讶，“原来我用的是这种模式呀！”，所以作为同样需要学习的我，我在编写这篇文章的初衷，并不是教大家使用设计模式，只能算是总结了23种设计模式，当我们脑海中已经形成了设计这个概念与思想时，那么我们已经开始进入设计模式的大门了，而无需去纠结设计模式的种类。前面我也提到过，已知设计模式已经超过百种，本人也只是了解这其中的冰山一角，又怎敢用这冰山一角的知识来去概括这设计模式四个大字呢？
在了解设计模式之前，我希望我们都能明白一个道理，那就说无论何种设计模式，其中心思想一定时提高代码灵活性；减少代码的复杂性；提高代码的可读性， 任何一个傻瓜都可以写出计算机可以理解的代码，唯有写出人类容易理解的代码，才是优秀的程序员。——Martin Fowler 《重构》。
高内聚，低耦合
高内聚通常是指一个软件的模块的内部组成关系比较紧凑，使得一个模块可以良好的完成一个任务；低耦合通常是指一个软件的模块与模块的之间不存在较为复杂的依赖，使得一个模块的变动对其他的模块影响较小。 高内聚低耦合通常是衡量一个软件设计中的模块的独立程度的标准，一个秉持“高内聚，低耦合”初衷开发出来的软件，其模块的复用性与可移植性通常都比那些“低内聚、高耦合”的软件高出不少，面向对象设计则是高内聚低耦合使用的佼佼者， 高内聚低耦合原则也是面向对象设计的重要核心之一。
设计模式六大原则
设计模式的七种原则就是高内聚低耦合的具体表现方式，不管以下何种原则，其目的都是为了贯穿“高内聚低耦合”的这么一个思想。
一、开闭原则（Open Close Principle）
开是指程序的对拓展开放，闭是指对程序的代码修改关闭，即不修改原有代码而达到拓展效果。
二、依赖倒转原则（Dependence Inversion Principle）
也是开闭原则的一种，即程序的编程要依赖于抽象，而非具体实现，即多使用接口与抽象类，少依赖具体类
三、里氏代换原则（Liskov Substitution Principle）
任何父类可以出现的地方，子类也一定可以出现。换句话说就是子类可以完全替代掉父类，在程序的角度，只有子类完全可以完全替代基类，程序才不会受到影响，父类才能算是被真正的被复用，子类也能在父类的基础上增加新的行为。
四、接口隔离原则（Interface Segregation Principle）
接口之间要独立且隔离，每个接口分工不同仅仅只能代表自己的一个角色，不应该合并成为一个接口，这样做不易维护。类与类之间依赖性应当建立在最小的接口上，而非所有接口上
五、迪米特原则（Demeter Principle）
迪米特原则也叫最少知道原则，即一个类对其它的类的介入应该越少越好，即对于被依赖的类，不管多么复杂，逻辑都尽量封装在内部，尽量少对外部暴露。
六、合成复用原则（Composite Reuse Principle）
尽量使用组合或者聚合的方式来复用一些已有的对象，使它们成为新对象的一部分，即多使用组合与聚合，少使用继承。
七、单一职责原则（Single responsibility principle）
单一职责原则也叫单一功能原职责，一个类应该只有一个发生变化的原因，只有一个职责，如果有多个职责，那么说明多个职责耦合在一起，这时一个职责发生变化后会影响到其它职责。举例，一个小镇上，小明是理发师，小张是医生，如果小明某天休息了，那么镇上的居民也仅仅只是无法理发而已，并不会影响看病；如果小明既是理发师又是医生，那么小明某天请假了之后，镇上的居民就既不能理发也不能看病。单一职责原则也是高内聚的具体表现之一
UML浅提
UML（Unified Modeling language），即统一建模语言，类似于流程图，但是更着重于编程语言，UML图会把程序中的一些基础单位以图像的方式表达出来，不管我们用UML图还是流程图，或者二者相结合，只要我们能够清晰的表达出开发者的一些想法即可。
语法
基本符号
类的表示
ps：方法无出参可省略不写
关系表示
示例
为什么我这里要提到UML，因为往后的内容里，大多数情况都会有UML图的出现。
Java设计模式分类
任何设计模式的核心要素还是在于它的意图，这才是它运用模式的潜在价值。根据《Design Patterns》一书，23种设计模式通过意图被分为了 5类，接口型模式、职责型模式、构造型模式、操作型模式、扩展性模式
| 模式意图 | 模式 |
|---|---|
| 接口型模式 | 适配器模式、外观模式、合成模式、桥接模式 |
| 职责型模式 | 单例模式、观察者模式、调停模式、代理模式、职责链模式、享元模式 |
| 构造型模式 | 构建者模式、工厂方法模式、抽象工厂模式、原型模式、备忘录模式 |
| 操作型模式 | 模板方法模式、状态模式、策略模式、命令模式、解释器模式 |
| 扩展型模式 | 装饰器模式、迭代器模式、访问者模式 |