关于后端:设计模式之单例和原型

明天这篇文章咱们来学习创立型设计模式的另外两个孪生兄弟，单例和原型，其中原型设计模式中咱们深刻到JVM的内存模型，最初顺便谈谈Java中的值传递和援用传递。

上篇文章老王买产品咱们从最原始的根本实现办法，到简略（动态）工厂，而后应用工厂办法设计模式进行革新，最初思考产品会产生变体，咱们又扩大到了形象工厂。

设计模式所有的相干代码均已上传到码云读者能够自行下载学习测试。

一、引出问题

明天老王又来了，还是想买咱们的产品，明天老王上老就提出来一个要求，当他购买产品的时候，每次都要从货架上给他拿雷同的一个。

如果用传统实现形式，当老王拿到产品当前，间接和上一个比对一下就行了，如果不统一老王就还回来。

但通过咱们查阅软件的七大设计准则，这很显著违反了依赖倒置准则，为了防止耦合和让代码更易于保护，老王是不能依赖具体产品的。

二、单例

咱们就须要将产品比对在创立产品的时候进行判断，老王就只管拿。

老王来之前应该还有两种状况，一种就是老王还没来，产品就筹备好了，也即饿汉式。第二种就是老王什么时候来，什么时候给他筹备产品，也即懒汉式。

咱们看具体的实现代码：

懒汉式：

/** * 懒汉式 * @author tcy * @Date 29-07-2022 */public class LazySingletonProduct {    private static volatile LazySingletonProduct instance=null;    private LazySingletonProduct(){}    public static synchronized LazySingletonProduct getInstance(){        if (instance==null){            instance=new LazySingletonProduct();        }        return instance;    }

饿汉式：

/** * 饿汉式 * @author tcy * @Date 29-07-2022 */public class HungrySingletonProduct {    private static volatile HungrySingletonProduct instance=new HungrySingletonProduct();    private HungrySingletonProduct(){};    public static synchronized HungrySingletonProduct getInstance(){        if (instance==null){            instance=new HungrySingletonProduct();        }        return instance;    }}

老王类：

/** * @author tcy * @Date 29-07-2022 */public class Client {    public static void main(String[] args) {        HungrySingletonProduct instance1 = HungrySingletonProduct.getInstance();        HungrySingletonProduct instance2 = HungrySingletonProduct.getInstance();        if (instance1==instance2){            System.out.println("我俩一样...");        }else {            System.out.println("我俩不一样...");        }    }}

以上就是单例设计模式中的懒汉式和饿汉式，应该是设计模式中最简略的一个，了解起来难度也不大。

为了克服老王和他儿子小王一起来拿错的难堪，咱们在办法上加synchronized锁，对象援用上加volatile共享变量，但这样会带来效率问题，如果不思考多线程需要，读者可自行去掉。

三、原型

老王明天很显著是找茬，他持续说，如果我不想要一个了，我要每次买都要不同的，你看着办。

每次创立产品都要不同的，传统的形式必定就是从新new一个对象，但每创立一个对象都是一个简单的过程，而且这样还会带来肯定的代码冗余。

这就须要用到创立型设计模式中的原型模式中的拷贝，其中又分为浅拷贝和深拷贝。

咱们先看基本概念。

浅克隆：创立一个新对象,对象种属性和原来对象的属性完全相同,对于非根本类型属性仍指向原有属性所指向的内存地址
深克隆：创立一个新对象,属性中援用类型也会被克隆,不再指向原来属性所指向的内存地址

这段意思也就是，老王购买产品的时候，如果产品都是根本数据类型（byte（位）、short（短整数）、int（整数）、long（长整数）、float（单精度）、double（双精度）、char（字符）和boolean（布尔值））和String,那么咱们就应用浅拷贝。

如果产品包含别的产品（对象）的援用类型就要应用深拷贝。

如果想搞明确，为什么造成深拷贝和浅拷贝这个问题，咱们就要重点说说JVM的内存模型。

咱们申明一个根本数据类型的变量a=2，实际上是在栈中间接存储了一个a=2，当拷贝的时候间接把值拷贝过来，也就是间接有了一份a的正本。

当咱们创立一个对象时Student stu=new Student()，实际上对象的值存储在堆中，在栈中只寄存了stu="对象地址"，stu指向了堆中的地址，jvm拷贝的时候只复制了栈中的地址，实际上他们堆中的对象还是一个。

咱们再来看String类型。String 存在于堆内存、常量池；这种比拟非凡, 传递是援用地址；由自身的final性, 每次赋值都是一个新的援用地址，原对象的援用和正本的援用互不影响。因而String就和根本数据类型一样,体现出了"深拷贝"个性。

咱们具体看实现代码：

浅拷贝类：

/** * @author tcy * @Date 29-07-2022 */public class ShallowProduct implements Cloneable{    private String name;    private int num;    public void show(){        System.out.println("这是浅产品..."+name+"数量："+num);    }    public String getName() {        return name;    }    public ShallowProduct setName(String name) {        this.name = name;        return this;    }    public int getNum() {        return num;    }    public ShallowProduct setNum(int num) {        this.num = num;        return this;    }    @Override    public ShallowProduct clone() throws CloneNotSupportedException {        return (ShallowProduct) super.clone();    }}

如果须要哪个对象浅拷贝，须要该对象实现Cloneable接口，并重写clone()办法。

public void shallowTest()throws CloneNotSupportedException{    ShallowProduct product1=new ShallowProduct();    ShallowProduct product2 = product1.clone();    product1.setName("老王");    product2.setName("老李");    product1.setNum(1);    product2.setNum(2);    product1.show();    product2.show();}

调用时输入的对象中的值间接就是两个不同的对象，实现了对象的浅拷贝。

如果该对象中包含援用类型呢?那怎么实现呢。

其实原理上也是很简略的，只须要将非根本数据类型也像浅拷贝那样操做就行了，而后在以后clone()办法中，调用非根本数据类型的clone()办法

深拷贝援用类：

/** * @author tcy * @Date 29-07-2022 */public class Child implements Cloneable{    private String childName;    public String getChildName() {        return childName;    }    public Child setChildName(String childName) {        this.childName = childName;        return this;    }    @Override    protected Child clone() throws CloneNotSupportedException {        return (Child) super.clone();    }}

深拷贝类：

/** * @author tcy * @Date 29-07-2022 */public class DeepProduct implements Cloneable{    private String name;    private Integer num;    private Child child;    public String getName() {        return name;    }    public DeepProduct setName(String name) {        this.name = name;        return this;    }    public Integer getNum() {        return num;    }    public DeepProduct setNum(Integer num) {        this.num = num;        return this;    }    public void show(){        System.out.println("这是深产品..."+name+"数量："+num+"包含child:"+child.getChildName());    }    @Override    public DeepProduct clone() throws CloneNotSupportedException {        DeepProduct clone = (DeepProduct) super.clone();        clone.child=child.clone();        return clone;    }    public Child getChild() {        return child;    }    public DeepProduct setChild(Child child) {        this.child = child;        return this;    }}

咱们测试一下对象中的值是否产生了扭转。

public void deepTest() throws CloneNotSupportedException {    DeepProduct product1=new DeepProduct();    Child child=new Child();    child.setChildName("老王child");    product1.setName("老王");    product1.setNum(1);    product1.setChild(child);    //--------------    DeepProduct product2=product1.clone();    product2.setName("老李");    product2.setNum(2);    product2.getChild().setChildName("老李child");    product1.show();    product2.show();}

老李、老王都正确的输入了，阐明实现没有问题。

这样就合乎了老王的要求。

既然说到了jvm的内存模型，就有必要说一下java中的值传递和援用传递。

实际上java应该就是值传递，在调用办法的时候，如果参数是根本数据类型，那么传递的就是正本，咱们在办法中无论怎么给他赋值，他本来的值都不会有变动。

在调用办法的时候，如果参数是援用数据类型，那么传递的就是这个对象的地址，咱们在办法中批改这个对象都会影响他本来的对象。

造成这个景象的起因其实是和浅拷贝、深拷贝的原理是一样的，都是栈、堆内存的构造导致的。

老王看他的要求都满足了，最初称心如意的拿着产品走了。