共计 4696 个字符，预计需要花费 12 分钟才能阅读完成。
建造者模式
1、什么是建造者模式
建造者模式: 是将一个简单的对象的构建与它的示意拆散，使得同样的构建过程能够创立不同的形式进行创立。
工厂类模式是提供的是创立单个类的产品
而建造者模式则是将各种产品集中起来进行治理，用来具备不同的属性的产品
建造者模式通常包含上面几个角色:
1、uilder: 给出一个形象接口，以标准产品对象的各个组成成分的建造。这个接口规定要实现简单对象的哪些局部的创立，并不波及具体的对象部件的创立。ConcreteBuilder: 实现 Builder 接口，针对不同的商业逻辑，具体化简单对象的各局部的创立。在建造过程实现后，提供产品的实例。3、Director: 调用具体建造者来创立简单对象的各个局部，在指导者中不波及具体产品的信息，只负责保障对象各局部残缺创立或按某种程序创立。Product: 要创立的简单对象。
2、建造者模式的应用场景
应用场景:
须要生成的对象具备简单的内部结构
须要生成的对象外部属性自身相互依赖。
与工厂模式的区别是: 建造者模式更加关注与整机拆卸的程序。
JAVA 中的 StringBuilder 就是建造者模式创立的，他把一个单个字符的 char 数组组合起来。Spring 不是建造者模式，它提供的操作应该是对于字符串自身的一些操作，而不是创立或扭转一个字符串。
单例模式
1、对于单例模式，谈谈你的理解吧
（1）单例模式是一种罕用的设计模式，单例模式比较简单但蕴含了对于线程平安、内存模型、类加载机制等一些比拟外围的知识点。
（2）单例模式就是在整个运行时域，一个类只有一个实例对象。
（3）为什么须要单例模式呢？因为有的类型的实例对象的创立和销毁对资源来说耗费不大，比方 string，然而有的类型呢就比较复杂宏大，如果频繁的创立和销毁对象并且这些对象齐全是能够复用的话，那么将会造成一些不必要的性能节约。
（4）举个例子吧，比方我当初要写一个拜访数据库的 demo，而创立数据库链接对象是一个耗资源的操作并且数据库链接齐全是能够复用的，那么我能够将这个对象设计成单例的，这样我只有创立一次并且重复使用这个对象就能够了，而不是每次都要去拜访数据库去创立一个链接对象。
3、实现 java 单例模式的几种模式？
(1)饿汉式一动态常量形式（线程平安）：
类加载时就初始化实例，防止了多线程同步问题，人造线程平安。
(2)饿汉式一动态代码块形式
（线程平安：其实就是在动态常量饿汉式实现上略微变动了一下，将类的实例化放在了动态代码块中而已，其余没区别。
(3)懒汉式（线程不平安）
这是最根本的实现形式，第一次调用才初始化，实现了懒加载的个性。多线程场景下禁止应用，因为可能会产生多个对象，不再是单例。
(4)懒汉式（线程平安，办法上加同步锁）
线程不平安懒汉式实现上惟一不同是：获取实例的 getInstance0 办法上加了同步锁。保障了多线程场景下的单例。然而效率会有所折损，不过还好。
(5)双重校验锁（线程平安，效率高）
此种实现中不必每次须要取得锁，缩小了获取锁和期待的事件。留神 volatile 关键字的应用，保障了各线程对 singleton 动态实例域批改的可见性。
(6)动态外部类实现单例（线程平安、效率高）
这种形式下 Singleton 类被装载了，instance 不肯定被初始化。因为 SingletonHolder 类没有被被动应用，只有通过显式调用 getInstance 办法时，才会显式装载 SingletonHolder 类，从而实例化 instance.。
4、java 单例模式的根本特点？
答：持有本人类型的属性：类结构器公有：对外提供获取实例的静态方法。
5、饿汉式和懒汉式的区别？
（1）线程平安方面：饿汉式天生就是线程平安的，能够间接用于多线程而不会呈现问题，懒汉式自身是非线程平安的。
（2）资源加载和性能方面：饿汉式在类创立的同时就实例化一个动态对象进去，不论之后会不会应用这个单例，都会占据肯定的内存，然而相应的，在第一次调用时速度也会更快，因为其资源曾经初始化实现，而懒汉式顾名思义，会提早加载，在第一次应用该单例的时候才会实例化对象进去，第一次调用时要做初始化，如果要做的工作比拟多，性能上会有些提早，之后就和饿汉式一样了。
工厂模式
001 什么是工厂设计模式？
工厂模式提供了一种创建对象的最佳形式。在工厂模式中，咱们在创建对象时不会对客户端裸露创立逻辑，并且是通过应用一个独特的接口来指向新创建的对象。实现了创建者和调用者拆散，工厂模式分为简略工厂、工厂办法、形象工厂模式。
002 什么是简略工厂模式？
简略工厂模式又叫静态方法模式（因为工厂类定义了一个静态方法）现实生活中，工厂是负责生产产品的；同样在设计模式中，简略工厂模式咱们能够了解为负责生产对象的一个类，称为“工厂类”。
003 简略工厂模式解决的问题？
将“类实例化的操作”与“应用对象的操作”离开，让使用者不必晓得具体参数就能够实例化出所须要的“产品”类，从而防止了在客户端代码中显式指定，实现理解耦。即使用者可间接生产产品而不须要晓得其生产的细节
004 简略工厂设计模式的实现。
简略工厂模式：把对象的创立放到一个工厂类中，通过参数来创立不同的对象。
005 简略工厂模式的长处？
将创立实例的工作与应用实例的工作离开，使用者不用关怀类对象如何创立，实现理解耦；
把初始化实例时的工作放到工厂里进行，使代码更容易保护。更合乎面向对象的准则 & 面向接口编程，而不是面向实现编程。
006 简略工厂模式的毛病？
1)工厂类集中了所有实例（产品）的创立逻辑，一旦这个工厂不能失常工作，整个零碎都会受到影响；
2)违反“凋谢 – 敞开准则”，一旦增加新产品就不得不批改工厂类的逻辑，这样就会造成工厂逻辑过于简单。
3)简略工厂模式因为应用了动态工厂办法，静态方法不能被继承和重写，会造成工厂角色无奈造成基于继承的等级构造。
007 简略工厂模式的利用场景？
客户如果只晓得传入工厂类的参数，对于如何创建对象的逻辑不关怀时；
当工厂类负责创立的对象（具体产品）比拟少时。
008 什么是工厂办法模式？
工厂办法模式，又称工厂模式、多态工厂模式和虚构结构器模式，通过定义工厂父类负责定义创建对象的公共接口，而子类则负责生成具体的对象。
009 工厂办法模式的具体实现。
工厂办法模式: 每种产品由一种工厂来创立，一个工厂解决一个对象。
角色组成
- 形象工厂: 定义工厂类所具备的根本的操作
- 具体工厂：该类必须继承形象工厂，实现形象工厂定义的办法，返回一个对象
- 形象产品：定义了形象产品具备的基本操作
- 产品实现类：实现形象产品类对定义的形象办法，和具体工厂一一对应；
010 工厂办法模式解决的问题？
工厂办法模式把具体产品的创立推延到工厂类的子类（具体工厂）中，此时工厂类不再负责所有产品的创立，而只是给出具体工厂必须实现的接口，这样工厂办法模式在增加新产品的时候就不批改工厂类逻辑而是增加新的工厂子类，合乎凋谢关闭准则，克服了简略工厂模式中毛病。
011 工厂办法模式的长处？
1)更合乎开 - 闭准则
新增一种产品时，只须要减少相应的具体产品类和相应的工厂子类即可
简略工厂模式须要批改工厂类的判断逻辑
2) 合乎繁多职责准则
每个具体工厂类只负责创立对应的产品
简略工厂中的工厂类存在简单的 switch 逻辑判断
3) 不应用动态工厂办法，能够造成基于继承的等级构造。
简略工厂模式的工厂类应用动态工厂办法
总结：工厂模式能够说是简略工厂模式的进一步形象和拓展，在保留了简略工厂的封装长处的同时，让扩大变得简略，让继承变得可行，减少了多态性的体现。
012 工厂办法模式的毛病？
1)增加新产品时，除了减少新产品类外，还要提供与之对应的具体工厂类，零碎类的个数将成对减少，在肯定水平上减少了零碎的复杂度；同时，有更多的类须要编译和运行，会给零碎带来一些额定的开销；
2)因为思考到零碎的可扩展性，须要引入形象层，在客户端代码中均应用形象层进行定义，减少了零碎的抽象性和了解难度，且在实现时可能须要用到 DOM、反射等技术，减少了零碎的实现难度。
3)尽管保障了工厂办法内的对批改敞开，但对于应用工厂办法的类，如果要更换另外一种产品，依然须要批改实例化的具体工厂类；一个具体工厂只能创立一种具体产品。
013 工厂办法模式的利用场景。
1)当一个类不晓得它所须要的对象的类时，在工厂办法模式中，客户端不须要晓得具体产品类的类名，只须要晓得所对应的工厂即可；
2)当一个类心愿通过其子类来指定创建对象时，在工厂办法模式中，对于形象工厂类只须要提供一个创立产品的接口，而由其子类来确定具体要创立的对象，利用面向对象的多态性和里氏代换准则，在程序运行时，子类对象将笼罩父类对象，从而使得零碎更容易扩大。
3)将创建对象的工作委托给多个工厂子类中的某一个，客户端在应用时能够毋庸关怀是哪一个工厂子类创立产品子类，须要时再动静指定，可将具体工厂类的类名存储在配置文件或数据库中。
014 什么是形象工厂模式？
形象工厂模式，即 Abstract Factory Pattern，提供一个创立一系列相干或相互依赖对象的接口，而无须指定它们具体的类；具体的工厂负责实现具体的产品实例。容许应用形象的接口来创立一组相干产品，而不须要晓得或关怀理论生产出的具体产品是什么，这样就能够从具体产品中被解耦。
015 形象工厂模式的具体实现。
形象工厂模式：工厂办法模式的进一步延长。
角色组成
- 形象工厂: 定义工厂类所具备的根本的操作
- 具体工厂：具体工厂实现了形象工厂，每个工厂办法返回多个具体对象
- 抽象类接口：定义了产品具备的基本操作, 提供一组所有类都具备的业务办法
- 抽象类：用于实现形象接口所定义的业务办法, 只做形象接口，具体由产品实现类解决
- 产品实现类：实现形象产品类对定义的形象办法，和具体工厂一对多；
016 形象工厂模式的长处。
1)升高耦合
形象工厂模式将具体产品的创立提早到具体工厂的子类中，这样将对象的创立封装起来，能够缩小客户端与具体产品类之间的依赖，从而使零碎耦合度低，这样更有利于前期的保护和扩大；
2)更合乎开 - 闭准则
新增一种产品类时，只须要减少相应的具体产品类和相应的工厂子类即可
3) 合乎繁多职责准则
每个具体工厂类只负责创立对应的产品
4) 不应用动态工厂办法，能够造成基于继承的等级构造。
017 形象工厂模式的毛病。
形象工厂模式很难反对新品种产品的变动。这是因为形象工厂接口中曾经确定了能够被创立的产品汇合，如果须要增加新产品，此时就必须去批改形象工厂的接口，这样就波及到形象工厂类的以及所有子类的扭转，这样也就违反了“开发——关闭”准则。
018 形象工厂模式的利用场景。
1)一个零碎不要求依赖产品类实例如何被创立、组合和表白的表白，这点也是所有工厂模式利用的前提。
2)这个零碎有多个系列产品，而零碎中只生产其中某一系列产品
3) 零碎要求提供一个产品类的库，所有产品以同样的接口呈现，客户端不须要依赖具体实现。
019 工厂模式和形象工厂模式比照？
工厂办法模式：具体工厂类只能创立一个具体产品类的实例。
形象工厂模式：具体工厂类能够创立多个具体产品类的实例。
原型模式
实用场景：
类初始化耗费资源较多。
new 产生的一个对象须要十分繁琐的过程（数据筹备、拜访权限等）。
构造函数比较复杂。
循环体中生产大量对象时。
长处：
性能低劣，Java 自带的原型模式是基于内存二进制流的拷贝，比间接 new 一个对象性能上晋升了许多。
能够应用深克隆形式保留对象的状态，应用原型模式将对象复制一份并将其状态保存起来，简化了创立的过程。
毛病：
必须装备克隆（或者可拷贝）办法。
当对已有类进行革新的时候，须要批改代码，违反了开闭准则。
深克隆、浅克隆须要使用切当。