百日筑基第二十三天-23种设计模式-创建型总汇
前言
设计模式可以说是对于七大设计原则的实现。
总体来说设计模式分为三大类:
- 创建型模式,共五种:单例模式、简单工厂模式、抽象工厂模式、建造者模式、原型模式。
- 结构型模式,共七种:适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
- 行为型模式,共十一种:策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
23种设计模式的关系图:
单例模式
简介
单例模式(Singleton Pattern)是 Java 中最简单的设计模式之一。这种类型的设计模式属于创建型模式,它提供了一种创建对象的最佳方式。这种模式涉及到一个单一的类,该类负责创建自己的对象,同时确保只有单个对象被创建(私有的构造器),这个类对外提供了唯一一种访问其实例的方式,对外只能够直接访问,不能实例化此类对象。例如,一台计算机上可以连接多台打印机,但是这个计算机上的打印程序只能有一个,这里就可以通过单例模式来避免两个打印作业同时输出到打印机中,即在整个的打印过程中只有一个打印程序的实例。
简单点说,单例模式(也叫单件模式)的作用就是保证在整个应用程序的生命周期中,任何时刻,单例类的实例都最多只存在一个。单例模式确保某一个类只有一个实例,而且自行实例化,并向整个系统提供这个实例单例模式。单例模式只应在有真正的“单一实例”需求时才可以使用。
单例的类图如下:其中 uniqueInstance 持有唯一的单例实例,类方法 getInstance() 用来获取唯一的实例化对象。
Singleton —————————————————————— -static uniqueInstance -other Attribute —————————————————————— +static genInstance()() +otherMethods()
8 种单例实现方式(有点多但有必要都看)
【1】饿汉式(静态常量)优缺点:
● 优点:这种写法比较简单,就是在类装载的时候就完成实例化。避免了线程同步问题。没有加锁,执行效率会提高。
● 缺点:在类装载的时候就完成实例化,没有达到 Lazy Loading 的效果。如果从始至终从未使用过这个实例,则会造成内存浪费,容易产生垃圾对象。
● 这种方式基于 classload 机制避免了多线程同步问题,instance 在类装载时就实例化,在单例模式中大多数都是调用 getInstance 方法,但是导致类装载的原因有很多种,因此通过其他方式(或者其他静态方法)导致类装载,此时初始化 instance就没有达到 Lazy Loading 的效果。
public class SingleTon {
//将构造器私有化,防止直接 New
private SingleTon(){}
//创建好一个私有的 SingleTon 实例
private static SingleTon instance = new SingleTon();
//提供一个 public 的静态方法, 可以返回 instance
public static SingleTon getInstance() {
return instance;
}
}
【2】饿汉式(静态代码块)优缺点:
● 这种方式和上面的方式其实类似,只不过将类实例化的过程放在了静态代码块中,也是在类装载的时候,就执行静态代码块中的代码,初始化类的实例。优缺点和上面一样。
● 结论:这种单例模式可用,但可能造成内存浪费。
public class SingleTon {
//将构造器私有化,防止直接 New
private SingleTon(){}
//创建好一个私有的 SingleTon 实例
private static SingleTon instance;
//静态块
static {
instance = new SingleTon();
}
//提供一个 public 的静态方法, 可以返回 instance
public static SingleTon getInstance() {
return instance;
}
}
【3】懒汉式(线程不安全)优缺点:
● 起到了 Lazy Loading 的效果,但是只能在单线程下使用。
● 如果在多线程下,一个线程进入if(singleton == null)判断语句块,还未来得及创建,另一个线程也通过了上述判断语句,这时便产生了多个实例。所以在多线程环境下不可使用这种方式。
● 结论:在实际开发中,不要使用这种方法。
public class SingleTon {
//将构造器私有化,防止直接 New
private SingleTon(){}
//创建好一个私有的 SingleTon 实例
private static SingleTon instance;
//提供一个 public 的静态方法, 可以返回 instance
public static SingleTon getInstance() {
if(instance == null) {
instance = new SingleTon();
}
return instance;
}
}
【4】懒汉式(线程安全,同步方法)优缺点:
● 解决了线程不安全问题。
● 效率太低了,每个线程在想获得类的实例的时候,执行 getInstance() 方法都要进行同步。而其实这个方法只执行一次实例化代码就够了,后面的想获得实例,直接 return 就够了。方法进行同步效率太低。
● 结论:在实际开发中不推荐使用。
public class SingleTon {
//将构造器私有化,防止直接 New
private SingleTon(){}
//创建好一个私有的 SingleTon 实例
private static SingleTon instance;
//提供一个 public 的静态方法, 可以返回 instance
public static synchronized SingleTon getInstance() {
if(instance == null) {
instance = new SingleTon();
}
return instance;
}
}
【5】懒汉式(线程安全,同步代码块)优缺点:
● 这种方式,本意是想对第四种实现方式的改进,因为前面同步方法效率太低, 改为同步产生实例化的的代码块。
● 但是这种同步并不能起到线程同步的作用。跟第3种实现方式遇到的情形一致,假如一个线程进入了 if (singleton == null) 判断语句块,还未来得及往下执行,另一个线程也通过了这个判断语句,这时便会产生多个实例。
● 结论:在实际开发中,不能使用这种方式。
public class SingleTon {
//将构造器私有化,防止直接 New
private SingleTon(){}
//创建好一个私有的 SingleTon 实例
private static SingleTon instance;
//提供一个 public 的静态方法, 可以返回 instance
public static SingleTon getInstance() {
if(instance == null) {
//添加同步代码块,提高了效率,多线程时存在创建的对象不一致风险
synchronized(SingleTon.class) {
instance = new SingleTon();
}
}
return instance;
}
}
【6】双重检查(Double-Check)优缺点:
● 双重检查概念是多线程开发中常使用到的,如代码所示,我们进行了两次 if(instance == null) 检查,这样就确保了线程的安全,同时也提高了效率。
● 这样,实例化代码只用执行一次,后面再次访问时,判断 if(instance == null) , 直接 return 实例化对象,也避免的反复进行方法同步。
● 线程安全;延迟加载;效率较高。
● 结论:在实际开发中,推荐使用这种单例设计模式。
public class SingleTon {
//将构造器私有化,防止直接 New
private SingleTon(){}
//创建好一个私有的 SingleTon 实例
private static volatile SingleTon instance;
//提供一个 public 的静态方法, 可以返回 instance
public static SingleTon getInstance() {
//添加同步代码块,提高了效率.
if(instance == null) {
synchronized(SingleTon.class) {
//解决多线程可能创建多个实例的情况
if(instance == null) {
instance = new SingleTon();
}
}
}
return instance;
}
}
【7】静态内部类优缺点:
● 这种方式采用了类加载器的机制来保证初始化实例时只有一个线程。
● 静态内部类方式在 SingleTon 类(父类)被装载时,不会导致内部类被装载,也就不会立即实例化,属于懒加载类型。当调用 getInstance() 方法时,才会装载 SingleTonInstance 类,从而完成 SingleTon 的实例化。
● 类的静态属性只会在第一次加载类的时候初始化,所以在这里,JVM 帮我们保证了线程的安全,在类初始化时,别的线程无法进入。
● 避免了线程不安全,利用静态内部类特点实现延迟加载,效率高。
● 结论:推荐使用。
public class SingleTon {
//将构造器私有化,防止直接 New
private SingleTon(){}
//在内部内中创建一个对象的实例,当父类 SingleTon 加载时,内部类 SingleTonInstance 无需加载
private static class SingleTonInstance{
private static final SingleTon INSTANCE = new SingleTon();
}
//提供一个 public 的静态方法, 可以返回 SingleTon实例
public static SingleTon getInstance() {
return SingleTonInstance.INSTANCE;
}
}
【8】枚举优缺点:
● 这借助JDK1.5中添加的枚举来实现单例模式。不仅能避免多线程同步问题,而且还能防止反序列化重新创建新的对象。
● 这种方式是Effective Java作者Josh Bloch 提倡的方式
● 结论:推荐使用
enum SingleTon {
//当只有一个对象时,就是单例
INSTANCE;
}
单例模式注意事项和使用场景
【1】单例模式保证了系统内存中该内只存在一个对象,节省了系统资源,对于一些需要频繁创建和销毁的对象,使用单例模式可以提高系统性能。
【2】当想实例化一个单例类的时候,必须要记住使用相应的获取对象的方法,而不是使用 new。
【3】单例模式使用场景:
- 需要频繁的进行创建和销毁对象
- 创建对象时耗时过多或消耗过多资源(既重量级对象)但又常使用的对象
- 工具类对象
- 频繁访问数据库或文件的对象(比如数据源、session工厂等)
工厂模式
简介
工厂模式(Factory Pattern)是 Java 中最常用的设计模式之一。这种类型的设计模式属于创建型模式,它提供了一种创建对象的最佳方式。在工厂模式中,我们在创建对象时不会对客户端暴露创建逻辑,并且是通过使用一个共同的接口来指向新创建的对象。简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例。简单工厂模式是工厂模式家族中最简单使用的模式。简单工厂模式定义了一个创建对象的类,由这个类来封装实例化对象的行为。在软件开发中,当我们会用到大量的创建某种、某类或者某批量对象时,就会使用到工厂模式。
简单工厂模式案例
【1】定义一个接口 Pizza
package com.yintong.principle.singleresponsibility;
//将Pizza 做成一个接口
public interface Pizza {
//准备原材料, 不同的披萨不一样,因此,我们做成抽象方法
public void prepare();
}
【2】定义披萨的种类,实现 Pizza 接口,如下定义了 GREEK、CHEESE 两种披萨。如果后续有新的种类可以实现 Pizza 接口,继续添加新的品种。
//希腊披萨
public class GreekPizza implements Pizza{
@Override
public void prepare() {
System.out.println(" 给希腊披萨 准备原材料 ");
}
}
//奶酪披萨
public class CheesePizza implements Pizza{
@Override
public void prepare() {
System.out.println(" 给制作奶酪披萨 准备原材料 ");
}
}
【3】 创建一个简单的工厂类对象 SimpleFactory
public class SimpleFactory {
//传入 orderType(种类) 返回对应的 Pizza 对象
public Pizza createPizza(String orderType) {
Pizza pizza = null;
//使用简单工厂模式
if (orderType.equals("greek")) {
//希腊披萨
pizza = new GreekPizza();
} else if (orderType.equals("cheese")) {
//奶酪披萨
pizza = new CheesePizza();
}
return pizza;
}
}
【4】在应用代码 OrderPizza 中调用工厂类,获取用户需要的披萨对象。
public class OrderPizza {
//定义用户要获取的披萨类型
private static final String pizza = "greek";
public static void main(String[] args) {
//通过工厂获取希腊披萨
SimpleFactory simpleFactory = new SimpleFactory();
//greekPizza 就是我们需要获取的目标披萨
Pizza greekPizza = simpleFactory.createPizza(pizza);
//调用目标披萨的方法
greekPizza.prepare();
}
}
简单工厂模式的优缺点
优点:
1)一个调用者想创建一个对象,只要知道其名称就可以了。
2)扩展性高,如果想增加一个产品,只要扩展一个工厂类就可以。
3)屏蔽产品的具体实现,调用者只关心产品接口。
缺点: 每增加一个产品时,都需要增加一个具体实现类和对象实现工厂,使得系统中类的个数成倍增加,在一定程度上增加了系统的复杂度,同时也增加了系统具体类的依赖。这并不是什么好事。
注意事项: 作为一种创建类模式,在任何需要生成复杂对象的地方,都可以使用工厂方法模式。有一点需要注意的地方就是复杂对象适合使用工厂模式,而简单对象,特别只需要通过 new 就可以完成创建的对象,无需工厂模式。如果使用工厂模式就需要使用工厂类,会增加系统的复杂度。
抽象工厂方法模式
需求: 在上述的基础上,添加了地区。例如:用户可以点北京的奶酪披萨,北京的胡椒披萨,或者伦敦的奶酪披萨,伦敦的胡椒披萨。
工厂方法设计模式:
1)、定义一个 interface(工厂的接口) 用于创建相关或者依赖关系的对象簇,而无需指明具体对象类。
2)、从设计层面来看,抽象工厂模式就是简单工厂模式的改进(或者称为进一步抽象)。
3)、将工厂抽象成两层,AbsFactory(抽象工厂)和具体实现的工厂子类。程序员可以根据创建对象类型使用对应的工厂子类。这样将单个的简单工厂类变成了工厂簇,更有利于代码的维护和扩展。
类图: 将简单工厂模式中的工厂类抽象成了一个接口,易于后期扩展。
【1】定义工厂类的接口(AbsFactory)
//一个抽象工厂模式的抽象层(接口)
public interface AbsFactory {
//让下面的工厂子类来 具体实现
public Pizza createPizza(String orderType);
}
【2】让北京和伦敦的工厂类实现此接口(与简单工厂类的区别就是实现了 AbsFactory 接口,伦敦略)
public class BJFactory implements AbsFactory{
//更加orderType 返回对应的Pizza 对象
public Pizza createPizza(String orderType) {
Pizza pizza = null;
//使用简单工厂模式
if (orderType.equals("greek")) {
//希腊披萨
pizza = new GreekPizza();
} else if (orderType.equals("cheese")) {
//奶酪披萨
pizza = new CheesePizza();
}
return pizza;
}
}
【3】在 Order 订单应用中,与接口 AbsFactory 进行组合。
public class OrderPizza {
AbsFactory factory;
//定义构造器
public OrderPizza(AbsFactory factory){
this.factory = factory;
}
//定义用户要获取的披萨类型,可以定义一个变量从客户端传入
private static final String pizza = "greek";
public void main(String[] args) {
//greekPizza 就是我们需要获取的目标披萨
Pizza greekPizza = factory.createPizza(pizza);
//调用目标披萨的方法
greekPizza.prepare();
}
}
工厂模式在 JDK-Calendar 类中的应用
//1、调用 Calendar 对象
Calendar instance = Calendar.getInstance();
//2、进入 Calendar.getInstance() 方法
public static Calendar getInstance()
{
return createCalendar(TimeZone.getDefault(),Locale.getDefault(Locale.Category.FORMAT));
}
//3、进入 createCalendar 方法
private static Calendar createCalendar(TimeZone zone,Locale aLocale){
CalendarProvider provider =
LocaleProviderAdapter.getAdapter(CalendarProvider.class, aLocale)
.getCalendarProvider();
if (provider != null) {
try {
return provider.getInstance(zone, aLocale);
} catch (IllegalArgumentException iae) {
// fall back to the default instantiation
}
}
Calendar cal = null;
if (aLocale.hasExtensions()) {
String caltype = aLocale.getUnicodeLocaleType("ca");
if (caltype != null) {
//这里就是我们要重点查看的部分,根据用户需求,创建Calendar 对象
switch (caltype) {
case "buddhist":
cal = new BuddhistCalendar(zone, aLocale);
break;
case "japanese":
cal = new JapaneseImperialCalendar(zone, aLocale);
break;
case "gregory":
cal = new GregorianCalendar(zone, aLocale);
break;
}
}
}
return cal;
}
工厂模式小结
1)工厂模式的意义: 将实例化对象的代码提取出来,放到一个类中统一管理和维护,达到和主项目的依赖关系的解耦。从而提高项目的扩展和维护性。
2)设计模式依赖抽象原则: 创建对象实例时,不要直接 new 类,而是把这个 new 类的动作放在一个工厂的方法中,并返回。不要让类继承具体类,而是继承抽象类或者实现 interface(接口)。不要覆盖基类中已经实现的方法。
建造者模式
简介
建造者模式(Builder Pattern): 使用简单的对象一步一步构建成一个复杂的对象。这种设计模式属于创建者模式,它提供了一种创建对象的最佳方式。一个 Builder 类会一步一步构造最终的对象。该 Builder 类是独立于其他对象的。例如,计算机是由 CPU、主板、内存、硬盘、显卡、机箱、显示器、键盘、鼠标等部件组装而成的,采购员不可能自己去组装计算机,而是将计算机的配置要求告诉计算机销售公司,计算机销售公司安排技术人员去组装计算机,然后再交给要买计算机的采购员。
以上所有这些产品都是由多个部件构成的,各个部件可以灵活选择,但其创建步骤都大同小异。这类产品的创建无法用前面介绍的工厂模式描述,只有建造者模式可以很好地描述该类产品的创建。
- 建造者模式: 又叫生成器模式,是一种对象构建模式。它可以将复杂对象的建造过程抽象出来(抽象类别),使这个抽象过程的不同实现方法可以构造出不同表现(属性)的对象。
- 建造者模式,它允许用户只通过指定复杂对象的类型和内容就可以构建它们,用户不需要知道内部的具体构建细节。
- 建造者模式主要解决在软件系统中,当面临一个复杂对象的创建工作时,其通常由各个部分的子对象用一定的算法构成;由于需求的变化,这个复杂对象的各个部分经常面临剧烈的变化,但是将它们组合在一起的算法却相对稳定。
- 主要适用于:一些基本部件不会变,而其组合经常变化的情况。主要是将变与不变进行分离(去肯德基,汉堡、可乐、薯条、炸鸡翅等是不变的,而其组合是经常变化的,生成出所谓的"套餐")。
建造者模式的四个角色
1)Product(产品角色): 包含多个组成部件的复杂对象(产品对象)。
2)Builder(抽象建造者): 创建一个包含 Product 各个子部件的抽象方法或接口,通常还包含了一个返回复杂产品的方法。
3)ConcreteBuilder(具体建造者): 实现 Builder 接口,构建和装备各个子部件的具体实现。
4)Director(指挥者): 构建一个使用 Builder 接口的对象。它主要作用是用于创建一个复杂的对象。在指挥者中不涉及具体产品的信息。主要分两个作用,一是隔离客户与对象的生产过程,二是负责控制对象的生产过程。
建造者模式的注意事项和细节
1)客户端不必知道产品内部组成的细节,将产品本身与产品的创建过程解耦,使得相同的创建过程可以创建不同的产品对象。
2)每一个具体建造者都相对独立,因此可以方便的替换或者新增具体建造者,用户使用不同的具体建造者即可得到不同的产品对象。
3)可以更加精准的控制产品的创建过程。将复杂产品的创建步骤分解在不同的方法中,使得创建过程更加清晰,也更方便使用程序来控制创建过程。
4)增加新的具体建筑者无需修改原有类库代码,指挥者类针对抽象建造者类编程,系统扩展方便。符合 OCP 原则。
5)建造者模式创建的产品具有较多的共同点,其组成部分相似,如果产品之间的差异性很大,则不适合建造者模式,因此其使用范围受到一定的限制。
6)如果产品的内部变化复杂,可能会导致需要定义很多具体建造者内来实现这种变化,导致系统变得庞大,因此这种情况下,考虑是否选择建造者模式。
7)抽象工厂模式 VS 建造者模式:抽象工厂模式实现对产品家族的创建,一个产品家族就是一系列产品。具有不同分类维度的产品组合,采用抽象工厂模式不需要关系构建过程,只关系产品由什么工厂生成即可。而建造者模式则是要求按照指定的蓝图建造产品,它主要目的是通过组装零配件而产生一个新产品。
建造者模式原理类图
建造者模式案例
【1】创建 Product 产品角色:
public class Product {
private String CPU;
//主板 mainboard
private String mainboard;
//内存 memory
private String memory;
//.....略
//生成get set 方法 略
}
【2】抽象建造者对象:
public abstract class Builder {
//组合 产品对象
protected Product product = new Product();
//抽象方法
public abstract void buildCpu();
public abstract void buildMainboard();
public abstract void buildMemory();
//返回一个产品对象
public Product getResult() {
return product;
}
}
【3】具体建造者对象:一般会有多个这种对象,都实现 Builder 抽象类。
public class ConcreteBuilder_huawei extends Builder{
@Override
public void buildCpu() {
product.setCPU("华为CPU");
}
@Override
public void buildMainboard() {
product.setMainboard("华为主板");
}
@Override
public void buildMemory() {
product.setMemory("华为内存");
}
}
【4】指挥者类,主要构建组装的流程:返回的是产品对象
public class Director {
//需要将抽象类聚合进来
Builder builder = null;
//创建一个构造器 调用时传入具体的实现类
public Director(Builder builder) {
this.builder = builder;
}
//添加set 方法 用户可以通过此方法修改已有的 建造者对象
public void setBuilder(Builder builder) {
this.builder = builder;
}
//笔记本的组成流程 返回的是产品类
public Product pack_pc() {
builder.buildMainboard();
builder.buildCpu();
builder.buildMemory();
return builder.getResult();
}
}
【5】客户端通过指挥者类调用需要的品牌电脑:
public class Client {
public static void main(String[] args) {
//创建需要的电脑子部件——例如我们要组装的是 华为
ConcreteBuilder_huawei huawei = new ConcreteBuilder_huawei();
//调用指挥者类,将需要的品牌传入,根据控制着中的流程进行组装
Director director = new Director(huawei);
//调用组装方法,返回产品
Product pack_pc = director.pack_pc();
//查看输入的结果
System.out.println(pack_pc.toString());
//结果为:Product [CPU=华为CPU, mainboard=华为主板, memory=华为内存]
}
}
源码分析(StringBuilder)
【1】java.lang.StringBuilder
中的建造者模式:
public class OrginBuilder {
public static void main(String[] args) {
StringBuilder builder = new StringBuilder("hello");
builder.append("world");
}
}
【2】进入 append 方法,会发现 StringBuilder 类即就是我们所说的指挥者。建造方法的具体实现是由 AbstractStringBuilder 实现。
@Override
public StringBuilder append(String str) {
super.append(str);
return this;
}
【3】进入 AbstractStringBuilder 类,实现了 Appendable 接口方法,此类已是建造者,只是不能实例化。
public AbstractStringBuilder append(String str) {
if (str == null)
return appendNull();
int len = str.length();
ensureCapacityInternal(count + len);
str.getChars(0, len, value, count);
count += len;
return this;
}
【4】Appendable 接口定义了多个 append 方法(抽象方法),既 Appendle 为抽象建造者,定义了抽象方法。
public interface Appendable {
Appendable append(CharSequence csq) throws IOException;
......
}
原型模式
简介
原型模式(Prototype Pattern): 是用于创建重复对象,同时又能保证性能。这种类型的设计模式属于创建型模式,它提供了一种创建对象的最佳方式。这种模式是实现了一个原型接口,该接口用于创建当前对象的克隆。当直接创建对象的代价比较大时,则采用这种模式。
思想: Java 中 Object 类是所有类的根类,Object 类提供了一个 clone() 方法,该方法可以将一个 Java 对象复制一份,但是需要实现 clone 的 Java 类必须要实现一个接口 Cloneable,该接口表示该类能够复制且具有复制的能力(原型模式)。
- 原型模式:用原型实例指定创建对象的种类,并且通过拷贝这些原型,创建新的对象。
- 原型模式是一种创建型设计模式,允许一个对象再创建另外一个可定制的对象,无需知道如何创建的细节。
- 工作原理是:通过将一个原型对象传给那个要发动创建的对象,这个要发动创建的对象通过请求原型对像拷贝它们自己来实现创建,及对象的clone()。
原理结构图说明:
1)Prototype:原型类,声明一个克隆自己的接口 clone。
2)ConcretePrototype:具体的原型类,实现一个克隆自己的操作。
3)Client 让一个原型对象克隆自己,从而创建一个新的对象(相当于属性)。
原型模式案例分析
【1】克隆类需要实现 Cloneable 重写 clone 方法。
package com.yintong.principle.singleresponsibility;
//写一个手机的克隆类
public class ConcretePrototype implements Cloneable{
//名称
private String name;
//号码
private Long number;
//构造器
public ConcretePrototype(String name, Long number) {
super();
this.name = name;
this.number = number;
}
@Override
public String toString() {
return "ConcretePrototype [name=" + name + ", number=" + number + "]";
}
// 克隆用到的主要部分
@Override
protected Object clone() throws CloneNotSupportedException {
ConcretePrototype ConcretePrototype = null;
try {
ConcretePrototype = (ConcretePrototype) super.clone();
}catch (Exception e) {
System.out.println(e.getMessage());
}
return ConcretePrototype;
}
}
【2】客户端调用 clone 方法,实现原型模式。
public class Client {
public static void main(String[] args) throws CloneNotSupportedException {
//创建一个对象
ConcretePrototype prototype = new ConcretePrototype("华为", new Long(1568889932));
//通过原型模式完成对象的创建 克隆
ConcretePrototype p2 = (ConcretePrototype)prototype.clone();
}
}
Spring 中的应用
【1】当 scope 配置为 prototype 时,表示原型模式。
<!-- 这里我们的 scope="prototype" 即 原型模式来创建 -->
<bean id="id01" class="com.atguigu.spring.bean.Monster" scope="prototype"/>
【2】查看底层调用:
else if (mbd.isPrototype()) {
// It's a prototype -> create a new instance.
Object prototypeInstance = null;
try {
beforePrototypeCreation(beanName);
prototypeInstance = createBean(beanName, mbd, args);
}
finally {
afterPrototypeCreation(beanName);
}
// *** 创建一个代理类 ***
bean = getObjectForBeanInstance(prototypeInstance, name, beanName, mbd);
}
浅拷贝
● 对于数据类型是基本数据类型的成员变量,浅拷贝会直接进行值传递,也就是将该属性值复制一份给新对象。
● 对于数据类型是引用类型的成员变量,比如说成员变量是某个数组、某个类的对象等,那么浅拷贝会进行引用传值,也就是只是将成员变量的引用值(内存地址)复制一份给新对象。因为实际上两个对象的该成员变量都指向同一个实例。在这种情况下,在一个对象中修改该成员变量会影响到另一个对象的该成员变量值。
● 浅拷贝是使用默认的 clone() 方法来实现。
深拷贝
● 复制对象的所有基本数据类型的成员变量值。
● 为所有引用数据类型的成员变量申请存储空间,并复制每个引用数据类型成员变量所引用的对象,直到该对象可达的所有对象。也就是说,对象进行深拷贝要对整个对象进行拷贝。
● 深拷贝的实现方式有两种,第一种是重写 clone 方法来实现深拷贝,第二种是通过序列化实现深拷贝,也是推荐的一种。
深拷贝的两种实现方法
【1】通过调用引用类型的克隆方法,实现深拷贝。缺点就是当引用类型多时,不建议采用。
public class DeepClone implements Cloneable{
//基本数据类型
private String name;
//引用数据类型
private Spare spare;
//重写clone方法,调用引用类型的克隆方法
@Override
protected Object clone() throws CloneNotSupportedException {
DeepClone deepClone = null;
deepClone = (DeepClone)super.clone();
//克隆引用数据类型
deepClone.spare = (Spare) spare.clone();
return deepClone;
}
}
【2】通过序列化的方式,实现深拷贝:也是建议使用的方法。
public class DeepClone implements Serializable{
/**
* 序列化 ID
*/
private static final long serialVersionUID = 1L;
//数据类型 略。。。。
//重写clone方法,调用引用类型的克隆方法
protected Object deepClone(){
ByteArrayOutputStream BOStream = null;
ObjectOutputStream OOSream = null;
ByteArrayInputStream BIStream = null;
ObjectInputStream OIStream =null;
try {
//序列化
BOStream = new ByteArrayOutputStream();
OOSream = new ObjectOutputStream(BOStream);
//将当前对象写入流中
OOSream.writeObject(this);
//反序列化
BIStream = new ByteArrayInputStream(BOStream.toByteArray());
OIStream = new ObjectInputStream(BIStream);
DeepClone deepClone = (DeepClone) OIStream.readObject();
return deepClone;
} catch (Exception e) {
e.printStackTrace();
return null;
}finally {
try {
BOStream.close();
OOSream.close();
BIStream.close();
OIStream.close();
} catch (Exception e2) {
e2.printStackTrace();
}
}
}
}
原型模式的注意事项和细节
1)创建新的对象比较复杂时,可以利用原型模式简化对象的创建过程,同时也能够提高效率。
2)不用重新初始化对象,而是动态地获得对象运行时的状态。
3)如果原始对象发生变化(增加或者减少属性),其他克隆对象也会发生变化,无需修改代码。
4)在实现深克隆的时候可能需要比较复杂的代码。
5)缺点:需要为每一个配置类配置一个克隆方法,这对全新的类来说不是很难,但对已有的类进行改造时,需要修改其源代码,违背了 ocp 原则。