码了好几年代码的打字机器我，对于设计模式这个词，肯定是一点也不陌生，但是对于设计模式的理解，因为日常开发中，增删改查较多，使用设计模式思想来优化代码的机会就很少。也不乏在翻阅源码的时候，叹服于别人优秀高效的设计。所有今天抽出点时间，对设计模式做个归纳、记录，以便日后读到优秀的源码，可以自信的说，这**不就是那啥吗，我也会写~~~
设计模式
设计模式（Design Pattern）是前辈们对代码开发经验的总结，是解决特定问题的一系列套路。它不是语法规定，而是一套用来提高代码可复用性、可维护性、可读性、稳健性以及安全性的解决方案
单例模式
饿汉模式
不管你需不需要，我都给你准备好，对于饿汉来说，心里踏实
饿汉模式很简单，提前提供实例对象 代码样例
public class SingleMan { private SingleMan() { } static { System.out.println("类加载"); } private static SingleMan instance = new SingleMan(); public static SingleMan getInstance() { return instance; } public void sayHello() { System.out.println("你好，相亲吗"); }}饿汉式与线程安全
实例在类加载时实例化，有JVM保证线程安全。
虚拟机在编译加载某个类的时候，会将所有类变量（static）、静态代码块（static{}）进行赋值。
虚拟机会在执行该操作时加锁，保证同一个类加载器下，一个类型只会初始化一次！
题外话： 类的加载时机
JVM只在需要某个类或者使用Class.forName(className)强制加载类的时候才会被调用，如果只是声明某个类的引用，而没有创建对象则不会加载该类
懒汉模式
懒汉模式，厨房有材料，鸡鸭鱼肉，饿得不行了，非吃不可了，才去做饭，此为懒汉
非线程安全的懒汉模式
public class SingleMan { private SingleMan() { } static { System.out.println("类加载"); } private static SingleMan instacne = null; public static SingleMan getInstance() { if (null == instacne) { instacne = new SingleMan(); } return instacne; } public void sayHello() { System.out.println("你好，相亲吗"); }}线程安全的懒汉模式
使用 双重检验锁
public class SingleMan { private SingleMan() { } static { System.out.println("类加载"); } private static SingleMan instacne = null; public static SingleMan getInstance() { if (null == instacne) { synchronized (SingleMan.class) { if (null == instacne) { //为什么两次判断，想想并发 instacne = new SingleMan(); } } } return instacne; } public void sayHello() { System.out.println("你好，相亲吗"); }}懒汉模式不推荐 在getInstance() 方法上加上 synchronized，性能太差了！
懒汉模式 与 volatile
双重检验锁堪称完美，但是还存在不足，问题出在 new SingleMan()上，这段代码在执行的时候，是非原子操作，不同线程交替会造成安全问题
解决很简单，只需要给类变量SingleMan 添加 volatile
volatile 的作用 ：
- 保证了不同线程对这个变量进行操作时的可见性，即一个线程修改了某个变量的值，这新值对其他线程来说是立即可见的
- 禁止进行指令重排序
public class SingleMan { private SingleMan() { } static { System.out.println("类加载"); } private volatile static SingleMan instacne; public static SingleMan getInstance() { if (null == instacne) { synchronized (SingleMan.class) { if (null == instacne) { //为什么两次判断，想想并发 instacne = new SingleMan(); } } } return instacne; } public void sayHello() { System.out.println("你好，相亲吗"); }}工厂模式
定义一个创建对象的接口，让其子类自己决定实例化哪一个工厂类，工厂模式使其创建过程延迟到子类进行
优点：
- 一个调用者想创建一个对象，只要知道其名称就可以了。
- 扩展性高，如果想增加一个产品，只要扩展一个工厂类就可以。
- 屏蔽产品的具体实现，调用者只关心产品的接口。
在任何需要生成复杂对象的地方，都可以使用工厂方法模式
简单工厂模式
看名字就简单，要不就不写了吧？ 哈哈
简单工厂模式 就是一个工厂类，里面有一个静态方法，根据我们不同的参数，返回不同的派生自同一个父类（或实现同一接口）的实例对象。
产品类：
public class Animal { void eat(){};}public class Cat extends Animal { @Override public void eat() { System.out.println("小猫吃鱼，喵喵喵~~~"); }}public class Dog extends Animal { @Override public void eat() { System.out.println("小狗吃骨头，汪汪~~~"); }}工厂：
public class AnimalFactory { public static Animal getInstance(String food) { if (food.equals("yu")) { return new Dog(); }else if (food.equals("gutou")) { return new Cat(); }else { return null; } }}测试：
public static void main(String[] args) { Animal animal1 = AnimalFactory.getInstance("yu"); animal1.eat(); Animal animal2 = AnimalFactory.getInstance("gutou"); animal2.eat();}小狗吃骨头，汪汪~~~小猫吃鱼，喵喵喵~~~
工厂模式
工厂模式，就是多个工厂的组合使用
//地球总厂interface EarthFactory{ Animal getInstance(String food);}//动物厂public class AnimalFactory implements EarthFactory{ @Override public Animal getInstance(String food) { if (food.equals("yu")) { return new Dog(); }else if (food.equals("gutou")) { return new Cat(); }else { return null; } }}//植物厂public class PlantFactory implements EarthFactory{ @Override public Animal getInstance(String food) { if (food.equals("yu")) { return new Tree(); }else if (food.equals("gutou")) { return new Grass(); }else { return null; } }}使用
public static void main(String[] args) { EarthFactory ef = new PlantFactory(); ef.getInstance("yu").eat();}虽然喂得都是 yu（鱼），但是不同东西，吃的效果就不一样了
抽象工厂模式
抽象工厂模式解决的就是工厂模式产品不匹配的问题
我想造一部手机，有两个工厂，分别定制 主板和外壳
使用 华为定制的主板，苹果定制的外壳，组装在一起，肯定会出问题。所以我们采用一个工厂生产一系列原配件的方式
- 主板和外壳
@Datapublic class Bord { private String name; public Bord(String name) { this.name = name; }}@Datapublic class Shell { private String name; public Shell(String name) { this.name = name; }}//华为主板栗子public class HuaweiBord extends Bord { public HuaweiBord(String name) { super(name); }}- 手机厂
public interface PhoneFactory { //造主板 Bord makeBord(); //造外壳 Shell makeShell();}//华为厂public class Huawei implements PhoneFactory { @Override public Bord makeBord() { System.out.println("造华为主板"); return new HuaweiBord("华为主板"); } @Override public Shell makeShell() { System.out.println("造华为外壳"); return new HuaweiShell("华为外壳"); }}//苹果厂public class Apple implements PhoneFactory { @Override public Bord makeBord() { System.out.println("造苹果主板"); return new AppleBord("苹果主板"); } @Override public Shell makeShell() { System.out.println("造苹果外壳"); return new AppleShell("苹果外壳"); }}- 富士康手机组装
public class Fushikang { private Bord bord; private Shell shell; public void build(PhoneFactory factory) { this.bord = factory.makeBord(); this.shell = factory.makeShell(); System.out.println(bord.getName() + " || " + shell.getName()); }}- 生成一台华为手机
public static void main(String[] args) { PhoneFactory huawei = new Huawei(); new Fushikang().build(huawei);}造华为主板
造华为外壳
华为主板 || 华为外壳
建造者模式
将一个复杂对象的构建与其表示分离，使得同样的构建过程可以创建不同的表示
就是我想组装一台手机， 手机组装的流程是一样的，但是相同的流程，使用不同的配件来组装，得到手机的配置也不一样。
简单地说就是 new xxBuilder().x().y().z().build();
- 手机
@Datapublic class Phone { private String cpu; private String screen; private Integer ram; private Phone() { } public Phone(String cpu, String screen, Integer ram) { this.cpu = cpu; this.screen = screen; this.ram = ram; }}- 手机建造者
public class PhoneBuilder { private Phone phone; private String cpu; private String screen; private Integer ram; public PhoneBuilder cpu(String cpu) { this.cpu = cpu; return this; } public PhoneBuilder screen(String screen) { this.screen = screen; return this; } public PhoneBuilder ram(Integer ram) { this.ram = ram; return this; } public Phone build() { return new Phone(this.cpu, this.screen, this.ram); }}- 建造手机
public static void main(String[] args) { Phone iphone = new PhoneBuilder().cpu("amd").screen("1920*1080").ram(16).build();}到这里，对于创建对象的创建型模式就先记录到这，原型模式就不介绍了，就是对对象的拷贝
下一篇有时间，记录一下代理模式，适配器模式等
更多好玩好看的内容，欢迎到我的博客交流，共同进步 WaterMin