写博客的初衷是以学习、记录、交流为主，文章中的思路是参照 Java开发中的23种设计模式详解，并加入了自己的一些思考和总结,参照的文章也是转载的，并指向 CSDN 博主终点，但未找到相应的文章，特此说明。
知乎中有框架与设计模式的区别的介绍。
分类
总体分为 3 大类：
创建型模式：
有 5 种，工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。结构型模式：
有 7 种，适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。行为型模式：
有 11 种，策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。其实还有两类：并发型模式和线程池模式。
六大原则
开闭原则（Open Close Principle）
对扩展开放，对修改关闭。
在程序需要进行拓展的时候，不能去修改原有的代码，类似于热插拔。
这是为了使程序具有扩展性，易于维护和升级。而想要达到这样的效果，我们需要使用接口和抽象类。
tips ：
重构，代码不够好的时候，也可以考虑重构， but 有成本。
扩展， 一代代码不够好的话，扩展相当于打补丁。
所以： 重构 + 基类 + 接口扩展
里氏代换原则 LSP
Liskov Substitution Principle
面向对象设计的基本原则之一。
任何基类可以出现的地方，子类一定可以出现。
LSP 是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。
里氏代换原则是对“开-闭”原则的补充。
实现 “开-闭原则” 的关键步骤就是抽象化。
而基类与子类的继承关系就是抽象化的具体实现，
里氏代换原则是对实现抽象化的具体步骤的规范。
tip： 扩展/衍生类/子类
前提：基类功能不受影响
手段：要复用基类功能
目的：扩展/增加新功能、新特性
依赖倒转原则
Dependence Inversion Principle
这是开闭原则的基础，具体内容：针对接口编程、依赖于抽象而不依赖于具体。
tips：针对接口或者基类编程，高层次代码不能依赖低层次代码
接口隔离原则
Interface Segregation Principle
使用多个隔离的接口，比使用单个接口要好。有降低类之间耦合度的意思。
设计模式的设计思想是从大型软件架构出发，为了升级和维护方便。降低依赖，降低耦合。
tips ：接口过多也不方便管理，适用即可。
高内聚，低耦合： 高内聚指的是单个类结构，是类的内部特征；低耦合指的是类与类之间的关系，是类的外部特征。
迪米特法则(最少知道原则)
Demeter Principle
一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。
tips：
不主动依赖，用构造传接口或者对象比 new 对象要好，
new 对象是非原子性操作，耦合并没有被消灭，只是被转移到了接口或者基类上
3 种解耦合的注入方式：构造注入，接口注入， setter 注入。
合成复用原则（Composite Reuse Principle）
原则是尽量使用合成/聚合的方式，而不是使用继承。
tips：
抽象/接口是最基础的，也是整体上的思想，
而合成是将一些已经有的模块组合成为新的模块功能，而不是一味的去创建
继承是有条件有代价的，继承是对已有功能的扩展但这种继承关系本身也是一种耦合，
设计所能做的是减少耦合，或者松耦合，或者转移耦合方式，而不是消灭耦合
耦合本身指的是两个同类（比如说模块）之间的紧密程度，在 Android 中可以理解为两个类之间的关系，
当设计可以让类与类之间的紧密关系降低时，我们就可以说是降低了耦合度，
但实际上又和基类或者接口耦合了，这种耦合可以视为一种规范或者标准化。
高内聚，低耦合：
是指模块内部的功能单一，模块与模块间的紧密关系小。
前者是指模块内部的关系，后者是指模块之间关系，两者不矛盾。
设计模式 1. 工厂方法： 3 种方式
共同的接口
public interface Sender {
public void Send();
}
实现类 1
public class MailSender implements Sender {
@Override
public void Send() {
System.out.println("this is mailsender!");
}
}
实现类 2
public class SmsSender implements Sender {
@Override
public void Send() {
System.out.println("this is sms sender!");
}
}
- 普通工厂类 –> 方式1
public class SendFactory {
public Sender produce(String type) {
if ("mail".equals(type)) {
return new MailSender();
} else if ("sms".equals(type)) {
return new SmsSender();
} else {
System.out.println("请输入正确的类型!");
return null;
}
}
}
- 多个工厂方法的工厂类 –> 方式 2
public Sender produceMail() {
return new MailSender();
}
public Sender produceSms() {
return new SmsSender();
}
- 静态工厂方法的工厂类 –> 方式 3
public class SendFactory {
public static Sender produceMail() {
return new MailSender();
}
public static Sender produceSms() {
return new SmsSender();
}
}
总体来说，简单工厂模式（工厂方法）适合：
凡是出现了大量的产品需要创建，并且具有共同的接口时，可以通过工厂方法模式进行创建。
在以上的三种模式中
第一种如果传入的字符串有误，不能正确创建对象
第三种相对于第二种，不需要实例化工厂类。
大多数情况下，我们会选用第三种 ——> [静态工厂方法模式]。
抽象工厂模式（Abstract Factory）
工厂方法模式有一个问题就是，类的创建依赖工厂类
也就是说，如果想要拓展程序，必须对工厂类进行修改，这违背了闭包原则： 不闭包可以理解为 ： 使用有条件的，有细节的，通用性要低
从设计角度考虑，有一定的问题，如何解决？
就用到抽象工厂模式，创建多个工厂类，这样一旦需要增加新的功能，直接增加新的工厂类就可以了，不需要修改之前的代码。
tips ：
这里把修改转移到了增加
修改对应的是原来的，而增加是扩展的 — > 遵循开闭原则，扩展而不是修改已有的
//1. 接口
public interface Sender {
public void Send();
}
//2. 接口实现类 1
public class MailSender implements Sender {
@Override
public void Send() {
System.out.println("this is mailsender!");
}
}
//2. 接口实现类 2
public class SmsSender implements Sender {
@Override
public void Send() {
System.out.println("this is sms sender!");
}
}
//3. 工厂接口
public interface Provider {
public Sender produce();
}
//4. 工厂类 1
public class SendMailFactory implements Provider {
@Override
public Sender produce(){
return new MailSender();
}
}
//4. 工厂类 2
public class SendSmsFactory implements Provider{
@Override
public Sender produce() {
return new SmsSender();
}
}
其实这个模式的好处就是，如果想增加一个功能：发及时信息，则只需
1.创建一个实现类（模块类），实现 Sender 接口
2.创建一个工厂类，实现 Provider 接口
就OK了，无需去改动现成的代码。这样做，拓展性较好！
tips：
扩展性的好坏不是一定的，项目的规模大小也会影响。
假设要增加 100 个模块类，那就要创建 200个类，这种情况下，该设计模式可能就不具有优势了。
单例模式（Singleton）
单例对象（Singleton）是一种常用的设计模式。
在Java应用中，单例对象能保证在一个JVM中，该对象只有一个实例存在。
这样的模式有几个好处：
1、某些类创建比较频繁，对于一些大型的对象，这是一笔很大的系统开销。
2、省去了 new 操作符，降低了系统内存的使用频率，减轻 GC 压力。
3、有些类如交易所的核心交易引擎，控制着交易流程，如果该类可以创建多个的话，系统完全乱了。
// 方式 1. 简单单例 不适用于多线程 – > 单例两种方式 1. 饿汉式：空间换时间 2. 懒汉式： 时间换空间 延时加载
public class Singleton {
/* 持有私有静态实例，防止被引用，此处赋值为null，目的是实现延迟加载 */
private static Singleton instance = null;
/* 私有构造方法，防止被实例化 */
private Singleton() {
}
/* 静态工程方法，创建实例 */
public static Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}
// 方式 2. 方法同步锁，锁类 ，影响性能
public static synchronized Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
// 方式 3. 双重锁机制 ---- > 懒汉式
public static Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class) {
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
// 饿汉式 ：直接创建对象
public class Singleton{
private static Singleton singleton = new Singleton ();
private Singleton (){}
public static Singleton getInstance(){
return singletion;
}
}
设计模式 4
建造者模式（Builder）
工厂类模式提供的是创建单个类的模式，而建造者模式则是将各种产品集中起来进行管理，用来创建复合对象，
所谓复合对象就是指某个类具有不同的属性。
// 借用以上 Sender 接口及其 2 个实现类
public class Builder {
private List<Sender> list = new ArrayList<Sender>();
public void produceMailSender(int count){
for(int i=0; i<count; i++){
list.add(new MailSender());
}
}
public void produceSmsSender(int count){
for(int i=0; i<count; i++){
list.add(new SmsSender());
}
}
}
从这点看出，建造者模式将很多功能集成到一个类里，这个类可以创造出比较复杂的东西。
所以与工程模式的区别就是：
工厂模式关注的是创建单个产品，而建造者模式则关注创建符合对象，多个部分。
因此，是选择工厂模式还是建造者模式，依实际情况而定。
tips ：框架中常见的一种使用场景是链式调用。
原型模式（Prototype）
原型模式虽然是创建型的模式，但是与工程模式没有关系，从名字即可看出，
该模式的思想就是：将一个对象作为原型，对其进行复制、克隆，产生一个和原对象类似的新对象。
public class Prototype implements Cloneable { // cloneable 是空方法
public Object clone() throws CloneNotSupportedException {
Prototype proto = (Prototype) super.clone();
return proto;
}
}
适配器模式
适配器模式将某个类的接口转换成客户端期望的另一个接口表示
目的是消除由于接口不匹配所造成的类的兼容性问题。
主要分为 3 类：
类的适配器模式、
对象的适配器模式、
接口的适配器模式。
核心思想就是：
- 有一个 Source 类，拥有一个方法，待适配
- 目标接口 Targetable，通过 Adapter 类，将 Source 的功能扩展到 Targetable 里。
类的适配器
// 1.1
public class Source {
public void method1() {
System.out.println("this is original method!");
}
}
// 1.2 接口
public interface Targetable {
/* 与原类中的方法相同 */
public void method1();
/* 新类的方法 */
public void method2();
}
// 1.3 类适配
public class Adapter extends Source implements Targetable {
@Override
public void method2() {
System.out.println("this is the targetable method!");
}
}
- 对象的适配器模式：
基本思路和类的适配器模式相同：
只是将Adapter类作修改，这次不继承Source类，而是持有Source类的实例，以达到解决兼容性的问题。
// 1.3 对象适配
public class Wrapper implements Targetable {
private Source source;
public Wrapper(Source source){
super();
this.source = source;
}
@Override
public void method2() {
System.out.println("this is the targetable method!");
}
@Override
public void method1() {
source.method1();
}
}
- 接口适配器
第三种适配器模式是接口的适配器模式，接口的适配器是这样的：
有时我们写的一个接口中有多个抽象方法，当我们写该接口的实现类时，
必须实现该接口的所有方法，这明显有时比较浪费，因为并不是所有的方法都是我们需要的，
有时只需要某一些，此处为了解决这个问题，我们引入了接口的适配器模式
借助于一个抽象类，该抽象类实现了该接口，
实现了所有的方法，而我们不和原始的接口打交道，只和该抽象类取得联系，
所以我们写一个类，继承该抽象类，重写我们需要的方法就行。
接口
public interface Sourceable {
public void method1();
public void method2();
}
抽象类
public abstract class Wrapper2 implements Sourceable{
public void method1(){}
public void method2(){}
}
子类1
public class SourceSub1 extends Wrapper2 {
// @Override //选择性重写
public void method1(){
System.out.println("the sourceable interface's first Sub1!");
}
}
子类 2
public class SourceSub2 extends Wrapper2 {
//@Override //选择性重写
public void method2(){
System.out.println("the sourceable interface's second Sub2!");
}
}
3 种适配器模式的应用场景：
类的适配器模式：
当希望将一个类转换成满足另一个新接口的类时，
可以使用类的适配器模式，创建一个新类，继承原有的类，实现新的接口即可。对象的适配器模式：
当希望将一个对象转换成满足另一个新接口的对象时，可以创建一个Wrapper类，
持有原类的一个实例，在Wrapper类的方法中，调用实例的方法就行。接口的适配器模式：
当不希望实现一个接口中所有的方法时，可以创建一个抽象类Wrapper，
实现所有方法，我们写别的类的时候，继承抽象类即可。
装饰者模式
顾名思义，装饰模式就是给一个对象增加一些新的功能，
而且是动态的，要求装饰对象和被装饰对象实现同一个接口，装饰对象持有被装饰对象的实例。
Source类是被装饰类，Decorator类是一个装饰类，可以为Source类动态的添加一些功能，代码如下：
// 1. 接口
public interface Sourceable {
public void method();
}
// 2. 被装饰类
public class Source implements Sourceable {
@Override
public void method() {
System.out.println("the original method!");
}
}
// 3. 装饰类
public class Decorator implements Sourceable {
private Sourceable source;
public Decorator(Sourceable source){
super();
this.source = source;
}
@Override
public void method() {
System.out.println("before decorator!");
source.method();
System.out.println("after decorator!");
}
}
tips ：好像不要接口也是可以的 不细究了，不过对于被装饰类的方法是私有的或者是不同的人操作的，可能要考虑一些问题了。
装饰器模式的应用场景：
1、需要扩展一个类的功能。
2、动态的为一个对象增加功能，而且还能动态撤销。（继承不能做到这一点，继承的功能是静态的，不能动态增删。）
缺点：产生过多相似的对象，不易排错！
代理模式
其实每个模式名称就表明了该模式的作用，代理模式就是多一个代理类出来，替原对象进行一些操作
e.g.比如我们在租房子的时候回去找中介，为什么呢？
因为你对该地区房屋的信息掌握的不够全面，希望找一个更熟悉的人去帮你做，此处的代理就是这个意思。
再如我们有的时候打官司，我们需要请律师，因为律师在法律方面有专长，可以替我们进行操作，表达我们的想法。
// 1.接口
public interface Sourceable {
public void method();
}
// 2. 实现类
public class Source implements Sourceable {
@Override
public void method() {
System.out.println("the original method!");
}
}
// 3. 代理类
public class Proxy implements Sourceable {
private Source source;
public Proxy(){
super();
this.source = new Source();
}
@Override
public void method() {
before();
source.method();
atfer();
}
private void before() {
System.out.println("before proxy!");
}
private void atfer() {
System.out.println("after proxy!");
}
}
代理模式的应用场景：
如果已有的方法在使用的时候需要对原有的方法进行改进，此时有 2 种办法：
1、修改原有的方法来适应。这样违反了“对扩展开放，对修改关闭”的原则。
2、就是采用一个代理类调用原有的方法，且对产生的结果进行控制。这种方法就是代理模式。
使用代理模式，可以将功能划分的更加清晰，有助于后期维护！
外观模式（Facade）
外观模式是为了解决类与类之间的依赖关系的，
像spring一样，可以将类和类之间的关系配置到配置文件中，
而外观模式就是将他们的关系放在一个Facade类中，降低了类类之间的耦合度，
该模式中没有涉及到接口
// cpu
public class CPU {
public void startup(){
System.out.println("cpu startup!");
}
public void shutdown(){
System.out.println("cpu shutdown!");
}
}
// memory
public class Memory {
public void startup(){
System.out.println("memory startup!");
}
public void shutdown(){
System.out.println("memory shutdown!");
}
}
// disk
public class Disk {
public void startup(){
System.out.println("disk startup!");
}
public void shutdown(){
System.out.println("disk shutdown!");
}
}
// 计算机
public class Computer {
private CPU cpu;
private Memory memory;
private Disk disk;
public Computer(){
cpu = new CPU();
memory = new Memory();
disk = new Disk();
}
public void startup(){
System.out.println("start the computer!");
cpu.startup();
memory.startup();
disk.startup();
System.out.println("start computer finished!");
}
public void shutdown(){
System.out.println("begin to close the computer!");
cpu.shutdown();
memory.shutdown();
disk.shutdown();
System.out.println("computer closed!");
}
}
// User 用户
public class User {
public static void main(String[] args) {
Computer computer = new Computer();
computer.startup();
computer.shutdown();
}
}
如果我们没有Computer类，那么，CPU、Memory、Disk他们之间将会相互持有实例，产生关系，
这样会造成严重的依赖，修改一个类，可能会带来其他类的修改，
这不是我们想要看到的，有了Computer类，他们之间的关系被放在了Computer类里，
这样就起到了解耦的作用，这，就是外观模式！
tips:
这个类之间的耦合也是蛮大 参考资料应该是 JAVA ，13 年的
桥接模式（Bridge）
桥接模式就是把事物和其具体实现分开，使他们可以各自独立的变化。
桥接的用意是：
将抽象化与实现化解耦，使得二者可以独立变化
像我们常用的JDBC桥DriverManager一样，JDBC进行连接数据库的时候，
在各个数据库之间进行切换，基本不需要动太多的代码，甚至丝毫不用动，
原因就是：
JDBC提供统一接口，每个数据库提供各自的实现，用一个叫做数据库驱动的程序来桥接就行了。
// 1. 接口：
public interface Sourceable {
public void method();
}
// 2.1 实现类 1
public class SourceSub1 implements Sourceable {
@Override
public void method() {
System.out.println("this is the first sub!");
}
}
// 2.2 实现类 2
public class SourceSub2 implements Sourceable {
@Override
public void method() {
System.out.println("this is the second sub!");
}
}
// 3. 定义一个桥，持有Sourceable的一个实例：
public abstract class Bridge {
private Sourceable source;
public void method(){
source.method();
}
public Sourceable getSource() {
return source;
}
public void setSource(Sourceable source) {
this.source = source;
}
}
public class MyBridge extends Bridge {
public void method(){
getSource().method();
}
}
这样，就通过对Bridge类的调用，实现了对接口Sourceable的实现类SourceSub1和SourceSub2的调用。
组合模式（Composite）
组合模式有时又叫部分-整体模式在处理类似树形结构的问题时比较方便
public class TreeNode {
private String name;
private TreeNode parent;
private Vector<TreeNode> children = new Vector<TreeNode>();
... setter getter
//添加孩子节点
public void add(TreeNode node){
children.add(node);
}
//删除孩子节点
public void remove(TreeNode node){
children.remove(node);
}
//取得孩子节点
public Enumeration<TreeNode> getChildren(){
return children.elements();
}
}
public class Tree {
TreeNode root = null;
public Tree(String name) {
root = new TreeNode(name);
}
public static void main(String[] args) {
Tree tree = new Tree("A");
TreeNode nodeB = new TreeNode("B");
TreeNode nodeC = new TreeNode("C");
nodeB.add(nodeC);
tree.root.add(nodeB);
System.out.println("build the tree finished!");
}
}
使用场景：
将多个对象组合在一起进行操作，常用于表示树形结构中，例如二叉树，数等。
享元模式（Flyweight）
享元模式的主要目的是实现对象的共享，即共享池，当系统中对象多的时候可以减少内存的开销，通常与工厂模式一起使用。
FlyWeightFactory负责创建和管理享元单元，当一个客户端请求时，
工厂需要检查当前对象池中是否有符合条件的对象，
1. 如果有，就返回已经存在的对象，
2. 如果没有，则创建一个新对象，FlyWeight是超类。
一提到共享池，我们很容易联想到Java里面的JDBC连接池，
想想每个连接的特点，我们不难总结出：
适用于作共享的一些个对象，他们有一些共有的属性：
就拿数据库连接池来说：
url、driverClassName、username、password及dbname，这些属性对于每个连接来说都是一样的，
所以就适合用享元模式来处理：
建一个工厂类，将上述类似属性作为内部数据，
其它的作为外部数据，在方法调用时，当做参数传进来，这样就节省了空间，减少了实例的数量。
// 数据库连接池的代码：
public class ConnectionPool {
private Vector<Connection> pool;
/*公有属性*/ // ---> public
private String url = "jdbc:mysql://localhost:3306/test";
private String username = "root";
private String password = "root";
private String driverClassName = "com.mysql.jdbc.Driver";
private int poolSize = 100;
private static ConnectionPool instance = null;
Connection conn = null;
/*构造方法，做一些初始化工作*/
private ConnectionPool() {
pool = new Vector<Connection>(poolSize);
for (int i = 0; i < poolSize; i++) {
try {
Class.forName(driverClassName);
conn = DriverManager.getConnection(url, username, password);
pool.add(conn);
} catch (ClassNotFoundException e) {
e.printStackTrace();
} catch (SQLException e) {
e.printStackTrace();
}
}
}
/* 返回连接到连接池 */
public synchronized void release() {
pool.add(conn);
}
/* 返回连接池中的一个数据库连接 */
public synchronized Connection getConnection() {
if (pool.size() > 0) {
Connection conn = pool.get(0);
pool.remove(conn);
return conn;
} else {
return null;
}
}
}
通过连接池的管理，实现了数据库连接的共享，不需要每一次都重新创建连接，节省了数据库重新创建的开销，提升了系统的性能！
第一类：通过父类与子类的关系进行实现。
第二类：两个类之间。
第三类：类的状态。
第四类：通过中间类
策略模式（strategy）
策略模式定义了一系列算法，并将每个算法封装起来，使他们可以相互替换，
且算法的变化不会影响到使用算法的客户。需要设计一个接口，为一系列实现类提供统一的方法，
多个实现类实现该接口，设计一个抽象类（可有可无，属于辅助类），提供辅助函数。
图中ICalculator提供同意的方法，
AbstractCalculator是辅助类，提供辅助方法，接下来，依次实现下每个类：
// 1. 统一接口：
public interface ICalculator {
public int calculate(String exp);
}
// 2. 辅助类：
public abstract class AbstractCalculator {
public int[] split(String exp,String opt){
String array[] = exp.split(opt);
int arrayInt[] = new int[2];
arrayInt[0] = Integer.parseInt(array[0]);
arrayInt[1] = Integer.parseInt(array[1]);
return arrayInt;
}
}
// 实现类 1
public class Plus extends AbstractCalculator implements ICalculator {
@Override
public int calculate(String exp) {
int arrayInt[] = split(exp,"\\+");
return arrayInt[0]+arrayInt[1];
}
}
// 实现类 2
public class Minus extends AbstractCalculator implements ICalculator {
@Override
public int calculate(String exp) {
int arrayInt[] = split(exp,"-");
return arrayInt[0]-arrayInt[1];
}
}
// 实现类 3
public class Multiply extends AbstractCalculator implements ICalculator {
@Override
public int calculate(String exp) {
int arrayInt[] = split(exp,"\\*");
return arrayInt[0]*arrayInt[1];
}
}
策略模式的决定权在用户，系统本身提供不同算法的实现，新增或者删除算法，对各种算法做封装。
因此，策略模式多用在算法决策系统中，外部用户只需要决定用哪个算法即可。
模板方法模式（Template Method）
模板方法模式：
1. 1 个抽象类中，有 1 个主方法，n 个抽象的或实际的方法
2. 继承抽象类，重写抽象方法，通过调用抽象类，实现对子类的调用
就是在 AbstractCalculator 类中定义一个主方法calculate，calculate()调用spilt()等，
Plus和Minus分别继承AbstractCalculator类，通过对AbstractCalculator的调用实现对子类的调用
public abstract class AbstractCalculator {
/*主方法，实现对本类其它方法的调用*/
public final int calculate(String exp,String opt){
int array[] = split(exp,opt);
return calculate(array[0],array[1]);
}
/*被子类重写的方法*/
abstract public int calculate(int num1,int num2);
public int[] split(String exp,String opt){
String array[] = exp.split(opt);
int arrayInt[] = new int[2];
arrayInt[0] = Integer.parseInt(array[0]);
arrayInt[1] = Integer.parseInt(array[1]);
return arrayInt;
}
}
public class Plus extends AbstractCalculator {
@Override
public int calculate(int num1,int num2) {
return num1 + num2;
}
}
我跟踪下这个小程序的执行过程：首先将exp和”\+”做参数，
调用AbstractCalculator类里的calculate(String,String)方法，
在calculate(String,String)里调用同类的split()，之后再调用calculate(int ,int)方法，
从这个方法进入到子类中，执行完return num1 + num2后，将值返回到AbstractCalculator类，
赋给result，打印出来。正好验证了我们开头的思路。
观察者模式（Observer）
包括这个模式在内的接下来的四个模式，都是类和类之间的关系，不涉及到继承，学的时候应该 记得归纳，
记得本文最开始的那个图。
观察者模式很好理解：
类似于邮件订阅和RSS订阅，
当我们浏览一些博客或wiki时，经常会看到RSS图标，就这的意思是，当你订阅了该文章，
如果后续有更新，会及时通知你。
简单来讲：
当一个对象变化时，其它依赖该对象的对象都会收到通知，
并且随着变化！对象之间是一种一对多的关系。
这些类的作用：
MySubject类就是我们的主对象，
Observer1和Observer2是依赖于MySubject的对象，
当MySubject变化时，Observer1和Observer2必然变化。
AbstractSubject类中定义着需要监控的对象列表，
可以对其进行修改：增加或删除被监控对象，且当MySubject变化时，负责通知在列表内存在的对象
// 一个Observer接口：
public interface Observer {
public void update();
}
// 实现类1
public class Observer1 implements Observer {
@Override
public void update() {
System.out.println("observer1 has received!");
}
}
// 实现类2
public class Observer2 implements Observer {
@Override
public void update() {
System.out.println("observer2 has received!");
}
}
//Subject接口及实现类：
public interface Subject {
/*增加观察者*/
public void add(Observer observer);
/*删除观察者*/
public void del(Observer observer);
/*通知所有的观察者*/
public void notifyObservers();
/*自身的操作*/
public void operation();
}
public abstract class AbstractSubject implements Subject {
private Vector<Observer> vector = new Vector<Observer>();
@Override
public void add(Observer observer) {
vector.add(observer);
}
@Override
public void del(Observer observer) {
vector.remove(observer);
}
@Override
public void notifyObservers() {
Enumeration<Observer> enumo = vector.elements();
while(enumo.hasMoreElements()){
enumo.nextElement().update();
}
}
}
public class MySubject extends AbstractSubject {
@Override
public void operation() {
System.out.println("update self!");
notifyObservers();
}
}
这些东西有些抽象，不太容易整体理解，
建议读者：根据关系图，新建项目，自己写代码（或者参考我的代码）,
按照总体思路走一遍，这样才能体会它的思想，理解起来容易！
迭代子模式（Iterator）
顾名思义，迭代器模式就是顺序访问聚集中的对象，一般来说，集合中非常常见，
如果对集合类比较熟悉的话，理解本模式会十分轻松。
这句话包含两层意思：
一是需要遍历的对象，即聚集对象
二是迭代器对象，用于对聚集对象进行遍历访问。
这个思路和我们常用的一模一样：
MyCollection中定义了集合的一些操作，MyIterator中定义了一系列迭代操作，且持有Collection实例
//接口 1
public interface Collection {
public Iterator iterator();
/*取得集合元素*/
public Object get(int i);
/*取得集合大小*/
public int size();
}
// 接口 2
public interface Iterator {
//前移
public Object previous();
//后移
public Object next();
public boolean hasNext();
//取得第一个元素
public Object first();
}
// 实现 1
public class MyCollection implements Collection {
public String string[] = {"A","B","C","D","E"};
@Override
public Iterator iterator() {
return new MyIterator(this);
}
@Override
public Object get(int i) {
return string[i];
}
@Override
public int size() {
return string.length;
}
}
// 实现 2
public class MyIterator implements Iterator {
private Collection collection;
private int pos = -1;
public MyIterator(Collection collection){
this.collection = collection;
}
@Override
public Object previous() {
if(pos > 0){
pos--;
}
return collection.get(pos);
}
@Override
public Object next() {
if(pos<collection.size()-1){
pos++;
}
return collection.get(pos);
}
@Override
public boolean hasNext() {
if(pos<collection.size()-1){
return true;
}else{
return false;
}
}
@Override
public Object first() {
pos = 0;
return collection.get(pos);
}
}
此处我们貌似模拟了一个集合类的过程，感觉是不是很爽？
其实JDK中各个类也都是这些基本的东西，加一些设计模式，再加一些优化放到一起的，
只要我们把这些东西学会了，掌握好了，我们也可以写出自己的集合类，甚至框架！
责任链模式（Chain of Responsibility）
责任链模式，有多个对象，每个对象持有对下一个对象的引用，这样就会形成一条链，
请求在这条链上传递，直到某一对象决定处理该请求。
但是发出者并不清楚到底最终那个对象会处理该请求，
所以，责任链模式可以实现，在隐瞒客户端的情况下，对系统进行动态的调整。
Abstracthandler类提供了get和set方法，方便MyHandle类设置和修改引用对象，
MyHandle类是核心，实例化后生成一系列相互持有的对象，构成一条链。
public interface Handler {
public void operator();
}
public abstract class AbstractHandler {
private Handler handler;
public Handler getHandler() {
return handler;
}
public void setHandler(Handler handler) {
this.handler = handler;
}
}
public class MyHandler extends AbstractHandler implements Handler {
private String name;
public MyHandler(String name) {
this.name = name;
}
@Override
public void operator() {
System.out.println(name+"deal!");
if(getHandler()!=null){
getHandler().operator();
}
}
}
此处强调一点就是：
链接上的请求可以是一条链，可以是一个树，
还可以是一个环，模式本身不约束这个，需要我们自己去实现，
同时，在一个时刻，命令只允许由一个对象传给另一个对象，而不允许传给多个对象。
命令模式（Command）
命令模式的理解：
举个例子，司令员下令让士兵去干件事情，
从整个事情的角度来考虑，司令员的作用是，发出口令，口令经过传递，
传到了士兵耳朵里，士兵去执行。这个过程好在，三者相互解耦，任何一方都不用去依赖其他人，
只需要做好自己的事儿就行，司令员要的是结果，不会去关注到底士兵是怎么实现的。
Invoker是调用者（司令员）
Receiver是被调用者（士兵）
MyCommand是命令，实现了Command接口，持有接收对象
public interface Command {
public void exe();
}
public class MyCommand implements Command {
private Receiver receiver;
public MyCommand(Receiver receiver) {
this.receiver = receiver;
}
@Override
public void exe() {
receiver.action();
}
}
public class Receiver {
public void action(){
System.out.println("command received!");
}
}
public class Invoker {
private Command command;
public Invoker(Command command) {
this.command = command;
}
public void action(){
command.exe();
}
}
public class Test {
public static void main(String[] args) {
Receiver receiver = new Receiver();
Command cmd = new MyCommand(receiver);
Invoker invoker = new Invoker(cmd);
invoker.action();
}
}
命令模式的目的就是达到命令的发出者和执行者之间解耦，实现请求和执行分开，
Struts中：
Struts其实就是一种将请求和呈现分离的技术，其中必然涉及命令模式的思想！
其实每个设计模式都是很重要的一种思想，看上去很熟，
其实是因为我们在学到的东西中都有涉及，尽管有时我们并不知道，
其实在Java本身的设计之中处处都有体现，像AWT、JDBC、集合类、IO管道或者是Web框架，
里面设计模式无处不在。因为我们篇幅有限，很难讲每一个设计模式都讲的很详细，
不过我会尽我所能，尽量在有限的空间和篇幅内，把意思写清楚了，更好让大家明白。
第三类和第四类。
备忘录模式（Memento）
主要目的是保存一个对象的某个状态，以便在适当的时候恢复对象，
叫备份模式更形象些
通俗的讲下：
假设有原始类A，A中有各种属性，
A可以决定需要备份的属性，备忘录类B是用来存储A的一些内部状态，类C呢，
就是一个用来存储备忘录的，且只能存储，不能修改等操作。
Original类是原始类，里面有需要保存的属性value及创建一个备忘录类，
用来保存value值。Memento类是备忘录类，Storage类是存储备忘录的类，
持有Memento类的实例，该模式很好理解。
public class Original {
private String value;
public String getValue() {
return value;
}
public void setValue(String value) {
this.value = value;
}
public Original(String value) {
this.value = value;
}
public Memento createMemento(){
return new Memento(value);
}
public void restoreMemento(Memento memento){
this.value = memento.getValue();
}
}
public class Memento {
private String value;
public Memento(String value) {
this.value = value;
}
public String getValue() {
return value;
}
public void setValue(String value) {
this.value = value;
}
}
public class Storage {
private Memento memento;
public Storage(Memento memento) {
this.memento = memento;
}
public Memento getMemento() {
return memento;
}
public void setMemento(Memento memento) {
this.memento = memento;
}
}
简单描述下：
新建原始类时，value被初始化为egg，后经过修改，
将value的值置为niu，最后倒数第二行进行恢复状态，
结果成功恢复了。其实我觉得这个模式叫“备份-恢复”模式最形象。
状态模式（State）
核心思想就是：
当对象的状态改变时，同时改变其行为，很好理解！
就拿QQ来说，有几种状态，在线、隐身、忙碌等，每个状态对应不同的操作，
而且你的好友也能看到你的状态，
所以，状态模式就两点：
1、可以通过改变状态来获得不同的行为。
2、你的好友能同时看到你的变化。
// State类是个状态类，Context类可以实现切换
public class State {
private String value;
public String getValue() {
return value;
}
public void setValue(String value) {
this.value = value;
}
public void method1(){
System.out.println("execute the first opt!");
}
public void method2(){
System.out.println("execute the second opt!");
}
}
public class Context {
private State state;
public Context(State state) {
this.state = state;
}
public State getState() {
return state;
}
public void setState(State state) {
this.state = state;
}
public void method() {
if (state.getValue().equals("state1")) {
state.method1();
} else if (state.getValue().equals("state2")) {
state.method2();
}
}
}
根据这个特性，状态模式在日常开发中用的挺多的，
尤其是做网站的时候，我们有时希望根据对象的某一属性，
区别开他们的一些功能，比如说简单的权限控制等。
访问者模式（Visitor）
访问者模式把数据结构和作用于结构上的操作解耦合，使得操作集合可相对自由地演化。
访问者模式适用于：
数据结构相对稳定算法又易变化的系统。
因为访问者模式使得算法操作增加变得容易。若系统数据结构对象易于变化，
经常有新的数据对象增加进来，则不适合使用访问者模式。
访问者模式的优点：
是增加操作很容易，因为增加操作意味着增加新的访问者。访问者模式将有关行为集中到一个访问者对象中，
其改变不影响系统数据结构。
其缺点是：
增加新的数据结构很困难。
简单来说:
访问者模式就是一种分离对象数据结构与行为的方法，通过这种分离，
可达到为一个被访问者动态添加新的操作而无需做其它的修改的效果。
// 一个Visitor类，存放要访问的对象，
public interface Visitor {
public void visit(Subject sub);
}
public class MyVisitor implements Visitor {
@Override
public void visit(Subject sub) {
System.out.println("visit the subject："+sub.getSubject());
}
}
// Subject类，accept方法，接受将要访问它的对象，getSubject()获取将要被访问的属性，
public interface Subject {
public void accept(Visitor visitor);
public String getSubject();
}
public class MySubject implements Subject {
@Override
public void accept(Visitor visitor) {
visitor.visit(this);
}
@Override
public String getSubject() {
return "love";
}
}
该模式适用场景：
如果我们想为一个现有的类增加新功能，不得不考虑几个事情：
1、新功能会不会与现有功能出现兼容性问题？
2、以后会不会再需要添加？
3、如果类不允许修改代码怎么办？
面对这些问题，最好的解决方法就是:
使用访问者模式，访问者模式适用于数据结构相对稳定的系统，把数据结构和算法解耦
中介者模式（Mediator）
中介者模式也是用来降低类类之间的耦合的：
因为如果类类之间有依赖关系的话，
不利于功能的拓展和维护，因为只要修改一个对象，其它关联的对象都得进行修改。
如果使用中介者模式，只需关心和Mediator类的关系，具体类类之间的关系及调度交给Mediator就行，
这有点像spring容器的作用。
User类统一接口，User1和User2分别是不同的对象，二者之间有关联
如果不采用中介者模式，则需要二者相互持有引用，这样二者的耦合度很高，
为了解耦，引入了Mediator类，提供统一接口，MyMediator为其实现类，
里面持有User1和User2的实例，用来实现对User1和User2的控制。
这样User1和User2两个对象相互独立，他们只需要保持好和Mediator之间的关系就行，
剩下的全由MyMediator类来维护！基本实现：
public interface Mediator {
public void createMediator();
public void workAll();
}
public class MyMediator implements Mediator {
private User user1;
private User user2;
public User getUser1() {
return user1;
}
public User getUser2() {
return user2;
}
@Override
public void createMediator() {
user1 = new User1(this);
user2 = new User2(this);
}
@Override
public void workAll() {
user1.work();
user2.work();
}
}
public abstract class User {
private Mediator mediator;
public Mediator getMediator(){
return mediator;
}
public User(Mediator mediator) {
this.mediator = mediator;
}
public abstract void work();
}
public class User1 extends User {
public User1(Mediator mediator){
super(mediator);
}
@Override
public void work() {
System.out.println("user1 exe!");
}
}
public class User2 extends User {
public User2(Mediator mediator){
super(mediator);
}
@Override
public void work() {
System.out.println("user2 exe!");
}
}
解释器模式（Interpreter）
一般主要应用在OOP开发中的编译器的开发中，所以适用面比较窄。
//Context类是一个上下文环境类，Plus和Minus分别是用来计算的实现
public interface Expression {
public int interpret(Context context);
}
public class Plus implements Expression {
@Override
public int interpret(Context context) {
return context.getNum1()+context.getNum2();
}
}
public class Minus implements Expression {
@Override
public int interpret(Context context) {
return context.getNum1()-context.getNum2();
}
}
public class Context {
private int num1;
private int num2;
public Context(int num1, int num2) {
this.num1 = num1;
this.num2 = num2;
}
public int getNum1() {
return num1;
}
public void setNum1(int num1) {
this.num1 = num1;
}
public int getNum2() {
return num2;
}
public void setNum2(int num2) {
this.num2 = num2;
}
}
基本就这样，解释器模式用来做各种各样的解释器，如正则表达式等的解释器等等！
