文章目录
 
设计模式
GoF设计模式
简要说明
1.创建型模式
1.1.0简单工厂模式
模式结构
    
1.1工厂方法模式
模式结构
应用实例
模式优缺点
适用场景
    
1.2抽象工厂模式
模式结构
应用实例
模式优缺点
适用场景
    
1.3建造者模式
模式结构
应用实例
钩子方法Hook Method
模式优缺点
适用场景
    
1.4原型模式
模式结构
应用实例
模式优缺点
适用场景
    
1.5单例模式
模式结构
应用实例
模式优缺点
适用场景
   
  
 

 
设计模式
 
设计模式是在特定环境下为解决某一通用软件设计问题提供的一套定制的解决方案，该方案描述了对象与类之间的相互作用
 
GoF设计模式
 
   在 1994 年，由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 四人合著出版了一本名为 Design Patterns - Elements of Reusable Object-Oriented Software（中文译名：设计模式 - 可复用的面向对象软件元素） 的书，该书首次提到了软件开发中设计模式的概念。
 
四位作者合称 GOF（四人帮，全拼 Gang of Four）。他们所提出的设计模式主要是基于以下的面向对象设计原则。
 
对接口编程而不是对实现编程。
优先使用对象组合而不是继承。
 
根据目的（模式是用来做什么的）可分为创建型（Creational），结构型（Structural），行为型（Behavioral）
 
范围 / 目的
创建型5
结构型7
行为型11
类模式
工厂方法模式
（类）适配器模式
解释器模式
模板方法模式
对象模式
抽象工厂模式
建造方法模式
原型模式
单例模式
（对象）适配器模式
桥接模式
组合模式
装饰者模式
外观模式
享元模式
代理模式
职责模式
命令模式
迭代器模式
中介者模式
备忘录模式
观察者模式
状态模式
策略模式
访问者模式

简要说明
 
模式类别
模式名称
模式说明
补充
角色
创建型模式（Creational）
工厂方法模式
定义一个用于创建对象的接口，但是让子类决定将哪一个类实例化。工程方法模式让一个类的实例化延迟到其子类
工厂方式模式提供一个抽象工厂接口来声明工厂方法，然后由其子类工厂类来实现工厂方法，创建具体的产品对象
1.抽象产品 2.具体产品 3.抽象工厂 4.具体工厂
抽象工厂模式
提供一个创建一系列类相关或相互依赖对象的接口，而无需指定它们具体的类
相对于类创建模式->工厂方法模式，对象创建模式抽象工厂模式提供的工厂类创建的具体对象并不简单是一个简单的对象，分成多种类型，处于同一个工厂类的产品形成产品系列。
1.抽象工厂 2.具体工厂 3.抽象产品 4.具体产品
建造者模式
将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示
建造者模式提供了一个抽象建造者来声明抽象的buildPartX()方法，具体建造过程在具体建造者中实现，此外还提供工厂方法getResult返回产品对象。通过注入产品对象的指挥者类完成产品的构建和组装。
1.抽象建造者 2.具体建造者 3.产品 4.指挥者
原型模式
使用原型实例指定待创建对象的类型，并且通过复制这个原型来创建新的对象
原型模式提供了一个抽象原型声明clone方法，返回类型为待创建产品类型的超类，具体原型实现clone方法，根据原型实例进行复制本身，返回新创建的对象
1.抽象原型 2.具体原型 3.客户
单例模式
确保一个类只有一个实例，并提供一个全局访问点来访问这个唯一实例
结构型模式（Structural）
适配器模式
将一个类的接口转化成客户希望的另一个接口。适配器模式让那些接口不兼容的类可以一起工作
桥接模式
将抽象部分和它的实现部分解耦，使得两者可以独立变化
组合模式
组合多对个对象形成树形结构以表示具有部分-整体关系的层次结构。组合模式让客户端可以统一对待单个对象和组合对象
装饰模式
动态地给一个对象增加一些额外的职责。就扩展功能而言，装饰模式提供了一种比使用子类更加灵活的替代方案
动态增强
外观模式
为子系统中的一组接口提供一个统一的入口。外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用
享元模式
运用共享技术有效地支持大量细粒度对象的复用
代理模式
给某一对象提供一个代理或占位符，并由代理对象来控制对原对象的访问
行为型模式（Behavioral）
职责链模式
避免将一个请求的发送者与接受者耦合在一起，让多个对象都有机会处理请求。将接受请求的对象连接成一条链，并且沿着这条链传递请求，直到有一个对象能够处理它为止
命令模式
将一个请求封装为一个对象，从而可用不同的请求对客户进行参数化，对请求排队或者记录请求日志，以及支持可撤销车操作
解释器模式
给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子
迭代器模式
提供一种方法顺序访问一个聚合对象中的各个元素，而又不用暴露该对象的内部表示
中介者模式
定义一个对象来封装一系列对象的交互。中介者模式使个对象之间不需要显示地互相吸引，从而使其耦合松散，而且可以独立地改变它们之间的交互
备忘录模式
在不破坏封装的前提下捕获一个对象的内部状态，并在该对象之外保存这个状态，这样可以在以后将对象恢复到原有保存的状态
观察者模式
定义对象对象之间的一种一对多依赖关系，使得每当一个对象状态发生改变时其相关依赖对象都得到通知并被自动更新
状态模式
允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类
策略模式
定义一系列算法，将每一个算法封装其来，并让它们可以相互替换。策略模式让算法可以独立于使用它的客户而变化
模板方法模式
定义一个操作中算法的框架，而将一些步骤延迟到子类中。模板方法模式使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤
访问者模式
表示一个作用于某对象结构中的各个元素的操作。访问者模式可以在不改变各元素的类的前提下定义作用于这些元素的新操作

1.创建型模式
 
1.1.0简单工厂模式
 
该模式不属于GoF的23种经典设计模式，但可作为学习其他工厂模式的基础
 
 
 
定义一个工厂类，它可以根据参数的不同返回不同类的实例，被创建的实例通常都具有公共的父类
 
 
由于在简单工厂模式中创建实例的方法通常是静态方法，因此简单工厂模式又被称为静态工程模式，它是一种类创建型模式。
 
模式结构
 
Factory工厂角色： 工厂类，提供静态的工厂方法factoryMethod()，返回类型为抽象产品类型Product
Product抽象产品角色： 它是所有工厂类创建的所有对象的父类（或接口），封装了各种产品对象的共有方法（子类继承父类的公有方法）。提供系统的灵活性，使得工厂类中只需定义一个通用的工厂方法，因为所有创建的具体产品对象都是其子类对象（或实现类对象）
ConcreteProduct具体产品角色： 它是简单工厂模式的创建目标，所有被创建的对象都充当这个角色的某个具体类的实例。每一个具体产品角色都继承了抽象产品角色，需要实现在抽象产品中声明的抽象方法
 
示例
 
package com.dust.DesignPatterns.Creational.SimpleFactory;

/**
 * @author dustdawn
 * @date 2019/10/31 16:02
 */
public abstract class Product {
    //所有产品类的公共业务方法
    public void methodSame() {

    }
    //声明抽象业务方法
    public abstract void methodDiff();
}
//=====================================================================================
package com.dust.DesignPatterns.Creational.SimpleFactory;

/**
 * @author dustdawn
 * @date 2019/10/31 16:07
 */
public class ConcreteProductA extends Product {
    @Override
    public void methodDiff() {
        //A业务方法
    }
}
//=====================================================================================
package com.dust.DesignPatterns.Creational.SimpleFactory;

/**
 * @author dustdawn
 * @date 2019/10/31 16:08
 */
public class ConcreteProductB extends Product {
    @Override
    public void methodDiff() {
        //B业务方法
    }
}
//=====================================================================================
package com.dust.DesignPatterns.Creational.SimpleFactory;

/**
 * @author dustdawn
 * @date 2019/10/31 16:04
 */
public class Factory {
    //静态工程方法
    public static Product getProduct(String arg) {
        Product product = null;
        //忽略大小写
        if (arg.equalsIgnoreCase("A")) {
            product = new ConcreteProductA();
        }else if (arg.equalsIgnoreCase("B")) {
            product = new ConcreteProductB();
        }
        return product;
    }

    public static void main(String[] args) {
        Product product;
        product = Factory.getProduct("A");
        product.methodSame();
        product.methodDiff();
    }
}


 
1.1工厂方法模式
 
简单工厂模式再增加新类型具体对象时，要修改工厂类的代码，一定程度上违反了开放封闭原则。而工厂方法模式将具体对象的创建过程交给了专门的工厂子类去实现。
 
定义一个抽象的工厂类，再定义具体的工厂类
 
工厂方式模式提供一个抽象工厂接口来声明工厂方法，然后由其子类工厂类来实现工厂方法，创建具体的产品对象
 
 
 
定义一个用于创建对象的接口，但是让子类决定将哪一个类实例化。工程方法模式让一个类的实例化延迟到其子类
 
 
模式结构
 
Product抽象产品角色： 定义产品的接口，是工厂方法模式所创建对象的父类型
ConcreteProduct具体产品角色： 实现了抽象产品接口，某种类型的具体产品由具体工厂创建，具体工厂与具体产品一一对应
Factory抽象工厂角色： 抽象工厂类，声明了工厂方法factoryMethod()，返回类型为抽象产品类型Product，所有创建对象的具体工厂类都必须实现该接口
ConcreteFactory具体工厂角色： 是抽象工厂类的子类或实现类，实现了在抽象工厂中声明的工厂方法，返回一个具体产品类的实例
 
示例
 
package com.dust.DesignPatterns.Creational.FactoryMethod;

import com.dust.DesignPatterns.Creational.SimpleFactory.Product;

/**
 * @author dustdawn
 * @date 2019/10/31 16:22
 */
public interface Factory {
    //抽象工厂，可以是接口，也可以是抽象类或者具体类
    public Product factoryMethod();
}
//=====================================================================================
package com.dust.DesignPatterns.Creational.FactoryMethod;

import com.dust.DesignPatterns.Creational.SimpleFactory.ConcreteProductA;
import com.dust.DesignPatterns.Creational.SimpleFactory.Product;

/**
 * @author dustdawn
 * @date 2019/10/31 16:24
 */
public class ConcreteFactoryA implements Factory{
    @Override
    public Product factoryMethod() {
        return new ConcreteProductA();
    }
}

 
   在实际使用时，具体工厂类在实现工厂方法时，除了创建具体产品对象以外，还可以负责产品对象的初始化工作以及一些资源和环境配置工作，例如连接数据库，创建文件等
 
应用实例
 
package com.dust.DesignPatterns.Creational.FactoryMethod;

/**
 * @author dustdawn
 * @date 2019/11/2 14:50
 */

/**
 * 日志记录器接口，充当抽象产品角色
 */
public interface Logger {
    public void writeLog();
}
//=====================================================================================
package com.dust.DesignPatterns.Creational.FactoryMethod;

/**
 * @author dustdawn
 * @date 2019/11/2 14:51
 */

/**
 * 文件日志记录器，充当具体产品角色
 */
public class FileLogger implements Logger{
    @Override
    public void writeLog() {
        System.out.println("文件日志记录");
    }
}
//=====================================================================================
package com.dust.DesignPatterns.Creational.FactoryMethod;

/**
 * @author dustdawn
 * @date 2019/11/2 14:50
 */

/**
 * 数据库日志记录器，充当具体产品角色
 */
public class DatabaseLogger implements Logger{
    @Override
    public void writeLog() {
        System.out.println("数据库日志记录");
    }
}
//=====================================================================================
package com.dust.DesignPatterns.Creational.FactoryMethod;

/**
 * @author dustdawn
 * @date 2019/11/2 14:51
 */

/**
 * 日志记录器工厂接口，充当抽象工厂角色
 */
public interface LoggerFactory {
    //抽象工厂方法
    public Logger createLogger();
}
//=====================================================================================
package com.dust.DesignPatterns.Creational.FactoryMethod;

/**
 * @author dustdawn
 * @date 2019/11/2 14:53
 */

/**
 * 文件日志记录器工厂类，充当具体工厂角色
 */
public class FileLoggerFactory implements LoggerFactory{
    @Override
    public Logger createLogger() {
        //创建文件日志记录器对象
        FileLogger fileLogger = new FileLogger();
        //创建文件，代码省略
        return fileLogger;
    }
}
//=====================================================================================
package com.dust.DesignPatterns.Creational.FactoryMethod;

/**
 * @author dustdawn
 * @date 2019/11/2 14:52
 */

/**
 * 数据库日志记录器工厂类，充当具体工厂角色
 */
public class DatabaseLoggerFactory implements LoggerFactory{
    @Override
    public Logger createLogger() {
        //连接数据库
        //创建数据库日志记录器对象
        DatabaseLogger databaseLogger = new DatabaseLogger();
        //初始化数据库日志记录器，代码省略
        return databaseLogger;
    }
}
//=====================================================================================
 
模式优缺点
 
优点：
 
向客户隐藏了哪一种具体产品类将被实例化这一细节，用户只需关心所需产品对应的工厂，无需关心创建细节。
将创建具体对象的细节完全封装在具体工厂内部，基于工厂角色和产品角色的多态性设计，所有的具体工厂类都具有同一抽象父类
系统加入产品时，无需修改抽象工厂和抽象产品提供的接口，也无需修改其他的具体工厂和具体产品，子类之间不形成耦合，只需要提供有一个具体工厂和具体产品即可。可扩展性好，完全符合开放封闭原则。
 
缺点：
 
添加新产品时，成对增加系统中类的个数，一定程度增加了系统的复杂度，更多的编译和运行给系统带来一些额外的开销
由于考虑到系统的可扩展性，需要引入抽象层，增加了系统的抽象性和理解程度
 
适用场景
 
当用户需要一个类的子类实例，并且不希望与该类的子类形成耦合或者不知道该类有哪些子类可用时，可采用工厂方法模式
不需要知道具体产品的类名，只需要知道锁对应的工厂即可，具体产品对象由具体工厂类创建，可将具体工厂类的类名存储在配置文件或数据库中
抽象工厂通过其子类来指定创建哪个对象。对于抽象工厂类，只需要提供一个创建产品的接口，而由其子类来确定具体要创建的对象。利用面向对象和多态性和里氏替换原则，在程序运行时子类对象将覆盖父类对象，从而使得系统容易扩展
 
1.2抽象工厂模式
 
当系统所提供的的工厂生产的具体产品并不是一个简单的对象，而是多个位于不同产品等级结构、属于不同类型的具体产品时就可以使用抽象工厂结构。
 
 
 
提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类
 
 
又称工具Kit模式，对象创建型模式
 
模式结构
 
AbstractFactory抽象工厂角色： 声明创建一组用于创建一个产品系列的方法（系列1，系列2…），每一个工厂方法对应一种产品（A,B,C,D…）
ConcreteFactory具体工厂角色： 实现了在抽象工厂中声明的创建产品的方法，生成一组具体产品，这些产品构成了一个系列的产品
AbstractProduct抽象产品角色： 为每种产品（A,B,C…）声明接口，在抽象产品中声明了产品具有的业务方法
ConcreteProduct具体产品角色： 定义具体工厂生成的具体产品对象，实现抽象产品接口中声明的业务方法
 
应用实例
 
在抽象工厂中声明多个工厂方法，用于创建不同类型的产品（A,B,C…），抽象工厂可以是接口，也可以是抽象类或具体类
 
package com.dustdawn.DesignPatterns.Creational.AbstractFactory;

/**
 * @author dustdawn
 * @date 2019/11/2 16:10
 */

/**
 * 抽象工厂方法角色
 */
public interface AbstractFactory {
    public AbstractProdustA createProductA();//工厂方法一
    public AbstractProdustB createProductB();//工厂方法二
}
 
具体工厂实现了抽象工厂，对每一个具体的工厂方法可以返回一个特定的产品对象。同一个具体工厂所创建的产品对象构成了一个产品对象构成一个产品系列。
 
package com.dustdawn.DesignPatterns.Creational.AbstractFactory;

/**
 * @author dustdawn
 * @date 2019/11/2 16:15
 */

/**
 * 具体工厂角色1
 */
public class ConcreteFactory1 implements AbstractFactory{
    @Override
    public AbstractProdustA createProductA() {
        return new ConcreteProductA1();
    }

    @Override
    public AbstractProdustB createProductB() {
        return new ConcreteProductB1();
    }
}
//...
 
模式优缺点
 
优点：
 
隔离了具体类的生成，使得客户端并不需要直到谁被创建。由于这种隔离，更换一个具体工厂容易。所有的具体工厂都实现了抽象工厂中定义的那些公共接口，只需要改变具体工厂的实例即可在某种程度下改变整个软件系统的行为。
当一个产品系列的多个对象设计成一起工作时，它能够保证客户端始终只使用同一个产品系列中的对象
增加新的产品系列很容易，无需修改已有系统，符合开放封闭原则
 
缺点：
 
增加产品类型复杂，需要对原有系统进行较大的修改，甚至需要修改抽象层代码，违背了开放封闭原则
 
适用场景
 
不依赖于产品类实例如何被创建，组合，表达的细节，无需关心对象的创建过程，将对象的创建和使用解耦
系统中有多于一个的产品系列，而每次只能使用其中某一类型产品，可以通过配置文件等方式来使用户能够动态改变和增加产品系列
属于同一种产品系列的产品将在一起被使用，这一约束必须在系统的设计中体现出来
产品等级结构稳定
 
1.3建造者模式
 
建造者模式是一种对象创建模式，将包含多个部件的复杂对象的创建过程分离，关注如何一步一步创建一个复杂的对象，不同的建造者定义了不同的创建过程
 
 
 
将一个复杂的对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示
 
 
模式结构
 
Builder抽象建造者： 它为创建一个产品对象的各个部件指定抽象接口，该接口中一般声明两类方法：一类方法是buildPartX()，它们用于创建复杂对象的各个部件；另一类是getResult()，它们用于返回复杂对象。Build既可以是抽象类，也可以是接口。
ConcreteBuild具体建造者： 实现了Builder接口，实现各个部件的具体构造和装配方法，定义并明确所常见的复杂对象，还可以提供一个方法返回创建好的复杂产品对象（也可以在抽象建造者中提供）
Product产品角色： 被构建的复杂对象，包含多个组成部件，具体建造者创建该产品的内部表示，并定义它的装配过程
Director指挥者角色： 负责安排复杂对象的建造次序，可以在其construct()建造方法中调用建造者对象的部件构造和装配方法完成对复杂对象的建造。用户与指挥者交互，确定具体建造者的类型，并实例化其对象。然后通过指挥者类的构造方法或者Setter方法将该对象传入指挥者类中
 
应用实例
 
package com.dustdawn.DesignPatterns.Creational.BuilderPattern;

/**
 * @author dustdawn
 * @date 2019/11/4 10:10
 */

/**
 * 复杂产品角色
 */
public class Product {
    private String partA;//部件
    private String partB;
    private String partC;

    //Getter和Setter方法
}
//=====================================================================================
 
在建造者类中定义了产品的创建和返回方法
 
package com.dustdawn.DesignPatterns.Creational.BuilderPattern;

/**
 * @author dustdawn
 * @date 2019/11/4 13:39
 */

/**
 * 抽象建造者类
 */
public abstract class Builder {
    //创建产品对象
    protected Product product = new Product();

    public abstract void buildPartA();
    public abstract void buildPartB();
    public abstract void buildPartC();

    //返回产品角色
    public Product getResult() {
        return product;
    }
}
 
具体建造者类实现抽象的建造方法
 
package com.dustdawn.DesignPatterns.Creational.BuilderPattern;

/**
 * @author dustdawn
 * @date 2019/11/4 13:42
 */

/**
 * 具体建造类
 */
public class ConcreteBuilder1 extends Builder{

    @Override
    public void buildPartA() {
        super.product.setPartA("A1");
    }

    @Override
    public void buildPartB() {
        super.product.setPartB("B1");
    }

    @Override
    public void buildPartC() {
        super.product.setPartC("C1");
    }
}
 
指挥者类Director作用：
 
隔离用户和创建过程
控制产品对象的创建过程，包括某个buildPartX()方法是否被调用以及多个方法的调用顺序
 
指挥者类可以注入一个抽象建造者类型的对象，它提供一个建造方法construct()，在该方法中调用了builder对象的构造部件的方法（利用多态特性由具体建造者对象实现），最后返回一个产品类型
 
package com.dustdawn.DesignPatterns.Creational.BuilderPattern;

/**
 * @author dustdawn
 * @date 2019/11/4 15:52
 */
public class Client {
    public static void main(String[] args) {
        ConcreteBuilder1 concreteBuilder1 = new ConcreteBuilder1();
        Director director = new Director(concreteBuilder1);
        Product product = director.construct();

    }
}
 
省略指挥者类，可将建造方法定义在抽象建造者中，如静态方法，通过静态方法完成建造过程，或成员方法，通过内部定义成员product和成员方法达到相同效果
 
钩子方法Hook Method
 
建造者模式除了逐步构建一个复杂产品对象外，还可以通过Director类更加精细地控制产品的创建过程。
 
可通过一类特殊方法钩子方法来控制是否对某个buildPartX()进行调用。
 
public boolean isBareheaded() {return false;}
 
抽象建造者类设置为false，具体建造者类设置为false重写方法
 
模式优缺点
 
优点：
 
用户不必知道产品内部组成的细节，将产品本身和产品的创建过程解耦，使得相同的创建过程能创建出不同的产品对象
每一个具体建造者都相对独立，方便替换。由于指挥者类针对抽象建造者编程，增加新的具体建造者类无需修改原有代码，系统扩展方便，符合开放封闭原则
更加精细地控制产品的创建过程。将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰，方便管理
 
缺点：
 
要求产品之间具有较多共同点（如设计不同游戏角色的模型自定义），产品之间差异性很大或很大组成部分不相同则不适合建造者模式
如果产品内部变化复杂，可能会导致需要许多具体建造者来实现，导致系统庞大，增加系统理解程度和运行成本
 
适用场景
 
需要生成的产品对象有复杂的内部结构，这些产品对象通常包括多个成员变量
需要生成的产品对象的属性相互依赖，需要指定其生成顺序
对象的创建过程独立于创建该对象的类。在建造者模式中通过指挥者类将创建过程封装在指挥者类中，而不在建造者类或用户类中
隔离复杂对象的创建和使用，并使相同的创建过程能创建出不同的产品
 
1.4原型模式
 
原型模式是一种对象创建型模式，将一个原型对象传给要发动创建的对象（即客户端对象），这个要发动创建的对象通过请求原型复制自己来实现创建过程。
 
 
 
使用原型实例指定待创建对象的类型，并且通过复制这个原型来创建新的对象
 
 
模式结构
 
Prototype抽象原型类： 声明克隆方法的接口，是所有具体原型类的公共父类，可以是抽象类，也可以是接口，甚至可以是具体实现类
ConcretePrototype具体原型类： 实现在抽象原型类中声明的克隆方法，在克隆方法中返回自己的一个克隆对象
Client类： 在客户类中，让一个原型对象克隆自身从而创建一个新的对象，只需要直接实例化或者通过工厂方法等方式创建一个原型对象，再通过该对象的克隆方法即可得到多个相同的对象。由于客户端针对抽象原型类Prototype编程，因此客户可以根据需要选择具体原型类，系统具有较好的扩展性，增加更换具体原型类都很方便。
 
根据复制原型对象的同时是否复制包含在原型对象中引用类型的成员变量，分为浅克隆（Shallow Clone）和深克隆（Deep Clone）
 
应用实例
 
通用实现
 
package com.dustdawn.DesignPatterns.Creational.PrototypePattern;

/**
 * @author dustdawn
 * @date 2019/11/4 15:56
 */

/**
 * 抽象原型类
 */
public abstract class Prototype {
    public abstract Prototype clone();
}
//=====================================================================================

package com.dustdawn.DesignPatterns.Creational.PrototypePattern;

/**
 * @author dustdawn
 * @date 2019/11/4 15:58
 */

/**
 * 具体原型类
 */
public class ConcretePrototype extends Prototype{
    private String str;//成员变量

    public String getStr() {
        return str;
    }

    public void setStr(String str) {
        this.str = str;
    }


    @Override
    public Prototype clone() {
        Prototype prototype = new ConcretePrototype();
        ((ConcretePrototype) prototype).setStr(this.str);
        return prototype;
    }
    
}
//=====================================================================================
 
 
Java中Clone方法和Cloneable接口（标识性接口，表示Java类支持被复制）
 
将Object类充当抽象原型类，ConcretePrototypeII充当具体原型类，Prototype充当成员类，实现对原型对象的复制（浅拷贝）
 
 
package com.dustdawn.DesignPatterns.Creational.PrototypePattern;

/**
 * @author dustdawn
 * @date 2019/11/4 16:04
 */
public class ConcretePrototypeII implements Cloneable{
    public Prototype clone() {
        Object object = null;
        try {
            object = super.clone();
        }catch (CloneNotSupportedException e) {
            System.err.println("Not support cloneable");
        }
        return (Prototype) object;
    }
}

 
模式优缺点
 
优点：
 
简化对象的创建过程，通过赋值一个已有实例可以提高新实例的创建效率
扩展性较好，针对抽象原型类进行编程，可将具体编程类写在配置文件中
提供简化的创建结构，通过封装在原型类中的克隆方法实现，无需专门的工厂类来创建产品
可以使用深克隆保存对象的状态，待需要时恢复，可辅助实现撤销操作
 
缺点：
 
需要为每一个类配备一个克隆方法，改造时需要修改源代码，违背了开放封闭原则
实现深克隆时需要编写较为复杂的代码，当对象之间存在多重的嵌套引用时，每一层对象都必须支持深克隆
 
适用场景
 
创建新对象成本比较大，新对象可以通过赋值已有对象来获得，如果相相似对象对其成员变量可以稍做修改
系统要保存对象的状态，而对象的状态变化很小
需要避免使用分层次的工厂类来创建分层次的对象，以及避免类的实例对象只有一个或很少的几个组合状态，通过复制原型对象得到新实例可能比使用构造函数创建一个新实例比较方便
 
1.5单例模式
 
保证一个类的实例只有一个并且这个实例易于访问
 
 
 
确保一个类只有一个实例，并提供一个全局访问点来访问这个唯一实例
 
 
模式结构
 
一个单例角色，单例类Singleton
内部创建唯一实例，并通过静态方法getInstance()让客户端可以使用它的唯一实例
防止外部对单例类实例化，将其构造函数的可见性设为private
在单例类内部定义了一个Singleton类型的静态对象作为供外部访问的唯一实例
 
实例
 
package com.dustdawn.DesignPatterns.Creational.SingletonPattern;

/**
 * @author dustdawn
 * @date 2019/11/5 14:42
 */

/**
 * 懒汉式单例模式
 * 线程安全，第一次调用初始化，避免资源浪费，
 * 但必须加锁才能保证单例，加锁影响效率
 */
public class SingletonI {
    private static SingletonI instance = null;//静态私有成员变量
    //私有构造函数
    private SingletonI() {}
    //静态共有工厂方法，返回唯一实例
    //保证线程安全
    public static synchronized SingletonI getInstance() {
        if (null == instance) {
            instance = new SingletonI();
        }
        return instance;
    }
}
//=====================================================================================
package com.dustdawn.DesignPatterns.Creational.SingletonPattern;

/**
 * @author dustdawn
 * @date 2019/11/5 14:48
 */

/**
 * 饿汉式单例模式
 * 没有加锁，但浪费资源，执行效率高
 */
public class SingletonII {
    private static SingletonII instance = new SingletonII();//静态私有成员变量
    //私有构造函数
    private SingletonII() {}
    //静态共有工厂方法，返回唯一实例
    public static synchronized SingletonII getInstance() {
        return instance;
    }
}

//=====================================================================================
package com.dustdawn.DesignPatterns.Creational.SingletonPattern;

/**
 * @author dustdawn
 * @date 2019/11/5 14:51
 */

/**
 * 静态内部类实现单例模式（登记类）
 */
public class SingletonIII {
    //通过静态内部类初始化的静态成员返回单例
    private static class SingletonHandler{
        private  static SingletonIII instance = new SingletonIII();
    }

    private SingletonIII(){}
    //在调用getInstance方法才初始化静态类
    public static SingletonIII getInstance() {
        return SingletonHandler.instance;
    }
}

//=====================================================================================
package com.dustdawn.DesignPatterns.Creational.SingletonPattern;

/**
 * @author dustdawn
 * @date 2019/11/5 14:54
 */

/**
 * 双重校验锁DCL的线程安全的单例模式
 */
public class Singleton {
    //volatile保证线程之间可见性和屏蔽JVM重排序
    //也会屏蔽一些JVM的代码优化导致运行效率低，所有也不完美
    private volatile static Singleton instance = null;

    private Singleton() {}

    public static Singleton getInstance() {
        //第一个if在已创建实例后直接返回实例，不再进入同步代码块竞争锁
        if (null != instance) {
            synchronized(Singleton.class) {
                //第二个if防止同时通过第一个if的多个线程创建多个实例
                if (null != instance) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}
 
应用实例
 
package com.dustdawn.DesignPatterns.Creational.SingletonPattern;

/**
 * @author dustdawn
 * @date 2019/11/5 15:03
 */

import java.util.ArrayList;
import java.util.List;
import java.util.Random;

/**
 * 场景：
 *  通过一个负载均衡器负责服务器的管理和请求的分支
 */
public class LoadBalancer {
    //负载均衡器单例角色
    private static LoadBalancer instance = null;
    //服务器集合角色
    private List serverList = null;
    //私有构造函数对服务器集合进行初始化
    private LoadBalancer() {
        serverList = new ArrayList();
    }

    public static LoadBalancer getLoadBalancer() {
        if (null != instance) {
            instance = new LoadBalancer();
        }
        return instance;
    }
    //增加服务器
    public void addServer(String server) {
        serverList.add(server);
    }
    //移除服务器
    public void removeServer(String server) {
        serverList.remove(server);
    }
    //获得服务器
    public String getServer() {
        Random random = new Random();
        int i = random.nextInt(serverList.size());
        return (String) serverList.get(i);
    }

}
 
模式优缺点
 
优点：
 
提供了对唯一实例的受控访问
由于在系统内存只有一个对象，所有可以节约系统资源，对于一些需要频繁创建和销毁的对象，单例模式无疑可以提高系统的性能
允许可变数目的实例
 
缺点：
 
没有抽象层，扩展困难
单例类的职责过重，一定程度违反了单一职责原则。既提供了业务方法，又提供了创建对象的方法，将对象的创建和对象本身的功能耦合在一起
垃圾回收器可能会自动销毁并回收长时间不被使用的实例对象，这会导致共享的单例对象状态的丢失
 
适用场景
 
系统只需要一个实例对象，或因为资源消耗太大而只允许创建一个对象
对单个实例只允许使用一个公共访问点，不可通过其他途径
频繁创建和销毁的对象的情形。如数据库连接池，读取配置的类，日志应用等。

实验项目二： 创建型设计模式实验
 
（1）实验目的与原理
 ①结合实例,熟练绘制创建型设计模式结构图。
 ②结合实例,熟练使用Java面向对象编程语言实现创建型设计模式。
 ③通过编程实践，理解每一种创建型设计模式的概念和内涵、结构、优缺点以及应用场景。
 （2）实验内容与步骤
 ①使用简单工厂模式设计一个可以创建不同几何形状( Shape)(例如圆形( Circle).、矩形 Rectangle)和三角形( ( Triangle)等的绘图工具类,每个几何图形均具有绘制方法daw()和擦除方法 erase(),要求在绘制不支持的几何图形时,抛出一个 UnsupportedShapeException异常。绘制类图并编程模拟实现。
 
②在某网络管理软件中,需要为不同的网络协议提供不同的连接类,例如针对POP3协议的连接类POP3Connection、针对IMAP协议的连接类 IMAPConnection、针对HTTP协议的连接类 HTTPConnection等。由于网络连接对象的创建过程较为复杂,需要将其创建过程封装到专门的类中,该软件还将支持更多类型的网络协议。现采用工厂方法模式进行设计,绘制类图并编程模拟实现。
 
③某系统为了改进数据库操作的性能,用户可以自定义数据库连接对象 Connection和语句对象 Statement,针对不同类型的数据库提供不同的连接对象和语句对象,例如提供 Oracle或 MySQL专用连接类和语句类,而且用户可以通过配置文件等方式根据实际需要动态更换系统数据库。使用抽象工厂模式设计该系统,绘制对应的类图并编程模拟实现。
 
④在某赛车游戏中,赛车包括方程式赛车、场地野赛车、运动汽车、卡车等类型,不同类型的赛车的车身、发动机、轮胎、变速箱等部件有所区别。玩家可以自行选择赛车类型,系统将根据玩家的选择创建出一辆完整的赛车。现采用建造者模式实现赛车的构建,绘制对应的类图并编程模拟实现
 
⑤某在线招聘网站中,用户可以创建一个简历模板。针对不同的工作岗位,可以复制该简历模板并进行适当修改后,生成一份新的简历。在复制简历时,用户可以选择是否复制简历中的照片:如果选择“是”,则照片将一同被复制,用户对新简历中的照片进行修改不会影响到简历模板中的照片,对模板进行修改也不会影响到新简历;如果选择“否”,则直接引用简历模板中的照片,修改简历模板中的照片将导致新简历中的照片一同修改,反之亦然。现采用原型模式设计该简历复制功能并提供浅克隆和深克隆两套实现方案,绘制对应的类图并编程模拟实现。
 
⑥某Web性能测试软件中包含一个虚拟用户生成器( Virtual User Generator)。为了避免生成的虚拟用户数量不一致,该测试软件在工作时只允许启动唯一一个虚拟用户生成器。采用单例模式设计该虚拟用户生成器,绘制类图并分别使用饿汉式单例、双重检测锁等二种方式编程模拟实现。
 
（3）实验过程
 第一题：简单工厂模式实现创建不同几何图形
 结构类图
 
 实现代码：
 
略
 
模拟测试截图
 
 第二题：工厂方法模式实现不同网络协议的连接
 结构类图
 
 
实现代码：
 
略
 
模拟测试截图
 
 
第三题：抽象工厂模式实现数据库的连接
 结构类图
 
 
实现代码：
 
略
 
模拟测试截图
 
 
第四题：建造者模式实现赛车的构建
 结构类图
 
 
实现代码：
 
略
 
模拟测试截图
 
 
第五题：原型模式通过浅克隆和深克隆方法实现该简历复制功能
 结构类图
 
 
实现代码：
 
略
 
模拟测试截图
 
 
第六题：单例模式设计虚拟用户生成器，使用饿汉式和双重检测
 结构类图
 
 
实现代码：
 
略
 
模拟测试截图
 
 详细的代码及操作

原型模式的原理与应用
 
如果对象的创建成本比较大，而同一个类的不同对象之间差别不大（大部分字段都相同），在这种情况下，我们可以利用对已有对象（原型）进行赋值（或者叫拷贝）的方式来创建新对象，达到节省创建时间的目的。这种基于原型来创建的方式就叫作原型设计模式（Prototype Design Pattern），简称原型模式。
 
为何“对象的创建成本比较大”
 
实际上，创建对象包含申请内存、给成员变量赋值这一过程，本身并不会花费太多时间，
 但是，如果对象中的数据需要经过复杂的计算才能得到（比如排序、计算哈希），或者从PRC、网络、数据库、文件系统等非常慢的IO中读取，这种情况下，我们就可以用原型模式，从其他已有对象中直接拷贝得到，而不用每次在创建新对象的时候，都重复执行这些耗时的操作。
 
深拷贝和浅拷贝
 
深拷贝和浅拷贝的区别在于，浅拷贝只会复制数据索引，不会复制数据本身。深拷贝不仅仅复制数据索引，还会复制数据本身。浅拷贝得到的对象跟原始对象共享数据，而深拷贝得到的是一份完完全全独立的对象。
 在Java语言中，Object类的clone()方法执行的就是浅拷贝。他会拷贝对象中的基本数据类型的数据，以及引用对象的内存地址（指针），不会递归的拷贝引用对象本身。
 不管采用哪种，深拷贝都要比浅拷贝耗时、耗内存空间。

目录
 
前言
 
读懂UML图
 
设计模式六大原则
 
设计模式分类
 
创建型模式原则
 
创建型模式 分析
 
1.简单工厂模式
 
2.工厂方法模式
 
3.抽象工厂方法模式
 
4.建造者模式
 
5.单例模式
 
6.原型模式
 
创建型模式 总结
 

前言
 
设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结，设计模式不是具体的代码，而是一种合理、易拓展、易维护的代码架构思想。设计模式被运用在各种优秀的框架中。掌握设计模式不仅能帮助我们更好的理解开源框架、亦能提升我们的编程能力。本文旨在总结常用设计模式的原理和常用场景。写作水平有限，不恰当处请指出。
 
读懂UML图
 
继承（extends）：带三角箭头的实线，箭头指向父类
实现关系（implements）：带三角箭头的虚线，箭头指向接口
依赖：带箭头的虚线，指向被使用者
关联 ：带普通箭头的实心线，指向被拥有者
聚合：带空心菱形的实心线，菱形指向整体
组合:带实心菱形的实线，菱形指向整体
 
设计模式六大原则
 
单一职责原则（SRP）：单个类只负责一项业务
里氏替换原则：子类功能要多于父类功能，但是不要修改父类功能，以免引起调用歧义
依赖倒置原则（面向接口编程）：调用接口时注入接口而不是具体实现
接口隔离原则：接口功能粒度要细，不要把所有的声明放到一个接口，利用java单继承多实现，分成多个接口
迪米特法则：不要引入无法管理的类，引入类要以成员变量形式。又称最少知道原则
开闭原则：对扩展开放，对修改关闭
设计模式分类
 
创建型模式，共五种：单例模式、工厂方法模式、抽象工厂模式、建造者模式、原型模式。
 
结构型模式，共七种：适配器模式、装饰者模式、代理模式、门面模式（外观模式）、桥梁模式、组合模式、享元模式。
 
行为型模式，共十一种：策略模式、模版方法模式、观察者模式、迭代器模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
 
创建型模式原则
 
创建型模式包括简单工厂模式、工厂方法模式、抽象工厂模式、建造者模式、单例模式，创建型模式模式遵循的设计原则如下：
 
解耦：把对象的创建和使用分离开
单一职责：工厂负责对象的创建和实例化，对于使用者来说创建过程是黑盒的
面向接口编程：使用者通过接口获取对象，易于分工、维护
创建型模式 分析
 
1.简单工厂模式
 
说明：我们把被创建的对象称为“产品”，把创建产品的对象称为“工厂”。如果要创建的产品不多，只要一个工厂类就可以完成，这种模式叫“简单工厂模式”。简单工厂模式属于不属于23种设计模式，它是工厂模式在简单场景下的一种应用。它的缺点是增加新产品时会违背“开闭原则”。
适用场景：简单工厂模式适用于产品(子类)较少的场景，例如图书馆管理系统中的用户类，它的实现类很固定，只有学生、教职工两种类型，在设计之初就可预见所有的类型，拓展的可能性很小，这种场景下适合使用简单工厂模式。
缺点：不满足开闭原则，难拓展
UML解读：product可以理解为图书馆用户类，ConcreateProduct1为学生类，ConcreateProduct2为教职工类，Factory为工厂，Client为使用用户类的业务。Client想要建一个学生类或者教职工，只要调用工厂方法并且传入对应类型，工厂方法便会返回相应类型。
 
2.工厂方法模式
 
 说明：工厂方法模式是对简单工厂模式的进一步抽象化，工厂方法模式满足开闭原则，可以更好的支持更好的支持多种产品(子类)、常扩展产品的业务场景。
使用场景：车辆售后维修系统的零件模块可以使用工厂方法模式，售后的零件是一个很灵活的业务场景，零件可以分为普通单个维修零件、套项零件(例如维修大灯总成的多个零件组合成的零件组)、技术升级零件(检查车辆可能存在的问题)。随着业务拓展会有更多的零件类型产生，如果使用简单工厂模式在新增了零件类型后就要修改原有代码适应新场景，修改同时可能会引入错误，不满足开闭原则。
缺点：每增加一个产品就要增加一个具体产品类和一个对应的具体工厂类，这增加了系统的复杂度。
UML解读：product1、product2为不同的零件类型，Factory1、Factory2为对应类型的工厂，它们都实现了AbStractFactory，Client为零件类的使用者。如果想要创建一个A零件就找A零件的工厂方法，如果想拓展一个新的零件类型就新增一个零件工厂和零件实体，这样就不会对老代码产生影响。
 
3.抽象工厂方法模式
 
 说明：工厂方法模式是工厂和商品一对一的模式，抽象工厂方法模式可以理解为一个工厂对一系列商品的情况。
使用场景：永辉超市要选择奶类食品供应商，采购的商品包括牛奶和酸奶，供应商包括蒙牛和伊利。蒙牛和伊利都是抽象工厂，因为它们都有生成系列产品的能力。
其缺点是：当产品族中需要增加一个新的产品时，所有的工厂类都需要进行修改。
UML解读：factory1和factory2分别代表蒙牛和伊利，product1*代表牛奶，product1*代表酸奶。
 
4.建造者模式
 
说明：建造者模式适用于整体对象由多个部件组成，且多个部件可以独立存在的情况，产品的组成部分是不变的，但每一部分是可以灵活选择的。
场景：组装汽车时需要用到发动机、车架、邮箱等零部件，零部件的生产相互独立，为汽车总成提供零件供应。在组装汽车时按照一定的顺序对零部件进行安装、调试，最终完成汽车的组装。汽车的最终组装者类似于电影导演的角色。
UML解读：Client是调用发起者，可以看作是外部触点，Director是导演类负责执行汽车的组装.BMBuilder和BenZBuilder实现了CarBuilder，CarModel 以及两个实现类 BenzModel 和 BMWModel 叫做产品类(Product Class)，这个产品类实现了模板方法模式。
 CarBuilder 以及两个实现类 BenzBuilder 和 BMWBuilder 叫做建造者(Builder Class)。
 
5.单例模式
 
说明：保证一个类只有一个实例，并提供一个全局访问点
场景：数据库连接池的设计、
优点：在内存中只有一个实例，减少内存开销、全局统一的访问点可以严格控制对象的访问
缺点：没有接口，扩展困难
UML图：客户端访问单例类，单例类负责控制任何情况下只有一个实例
 
 
 
单例模式学习友情链接：
 
单例模式的懒汉式为什么是线程不安全的，懒汉式如何实现线程安全
 
序列化、反序列化对单例的破坏、原因分析、解决方案及解析
 
6.原型模式
 
说明:原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象
特点:不需要知道任何创建的细节，不调用构造函数
场景:类初始化效果过多资源、new产生的一个对象需要非常繁琐的过程（数据准备、访问权限控制）、构造函数比较复杂、循环体中产生大量的对象。
优点:使用原型模式创建对象比直接new对象的性能高、简化创建过程
缺点:必须配备克隆方法、克隆复杂对象或克隆出的对象进行复杂性改造时容易引入风险、对复杂对象深拷贝、浅拷贝要运用得当
扩展:深克隆、浅克隆区别与使用
原型模式学习友情链接：
 
原型模式的使用案例、克隆复合对象出现的问题及解决方案、深克隆和浅克隆的区别
 
创建型模式 总结
 
简单工厂方法：把所有对象的创建，集中到一个类中处理
工厂方法模式：一个工厂负责一个产品的创建
抽象工厂模式：将一系列的产品抽象到同一个工厂创建
建造者模式：对象的创建比较复杂时，按照步骤一块块创建，让创建过程模板化
单例模式：控制实例数量，确保一个类只有一个实例
原型模式：用于低消耗的创建对象
图片、部分文字出处如下(侵删)：
 
C语言中文网《设计模式》