设计模式
1.工厂模式
背景: 我们需要生产两款车: BMW320和BMW523
public class BMW320 {
}
public class BMW523 {
}
在没有工厂模式之前, 我们只能自己手动创建(new)这几款车
public static void main(String[] args) {
BMW320 bmw320 = new BMW320();
BMW523 bmw523 = new BMW523();
}
之后就出现了工厂, 使用工厂可以封装对象的创建逻辑,提高代码的灵活性、可维护性和可扩展性,同时降低客户端代码与具体产品类的耦合度。
1.1 简单工厂模式
代码改造:
- 产品类: 继承同一个共性类(抽象类)
// 抽象类
abstract class BMW {
}
// 实现类
public class BMW320 extends BMW {
}
// 实现类
public class BMW523 extends BMW {
}
- 工厂类: 提供创建产品的通用方法
public class Factory {
public BMW createBMW(int type) {
switch (type) {
case 320:
return new BMW320();
case 523:
return new BMW523();
default:
break;
}
return null;
}
}
- 生产者: 通过工厂获取对象
public static void main(String[] args) {
Factory factory = new Factory();
BMW bmw320 = factory.createBMW(320);
BMW bmw523 = factory.createBMW(523);
}
简易工厂模式的优缺点:
- 优点
- 封装对象创建逻辑: 工厂封装了对象的创建逻辑, 生产者无需了解具体的对象创建逻辑.这提高了代码的
可读性
、可维护性
、复用性
- 松耦合: 生产者直接通过工厂来获取对象, 只需要知道产品类所需的具体参数即可
- 封装对象创建逻辑: 工厂封装了对象的创建逻辑, 生产者无需了解具体的对象创建逻辑.这提高了代码的
- 缺点
- 不符合开放-封闭原则: 当需要添加新的产品类时, 需要改动工厂类的代码, 违反了开发-封闭原则
- 违背单一职责原则: 简单工厂模式通常将多个产品的创建逻辑都集中在一个工厂类中, 这可能导致该工厂类的职责过于庞大, 不符合单一职责原则
1.2 工厂方法模式
工厂方法模式将工厂抽象化,并定义一个创建对象的接口。每增加新产品,只需增加该产品以及对应的具体实现工厂类,由具体工厂类决定要实例化的产品是哪个,将对象的创建与实例化延迟到子类,这样工厂的设计就符合“开闭原则”了,扩展时不必去修改原来的代码。
代码改造:
- 产品类不改动
- 工厂类: 工厂抽象化, 每新增一个产品, 只需要增加该产品的具体实现工厂类
interface FactoryBMW {
BMW createBMW();
}
public class FactoryBMW320 implements FactoryBMW {
@Override
public BMW320 createBMW() {
return new BMW320();
}
}
public class FactoryBMW523 implements FactoryBMW {
@Override
public BMW523 createBMW() {
return new BMW523();
}
}
- 生产者: 由具体工厂类决定要实例化的产品是哪个
public static void main(String[] args) {
FactoryBMW320 factoryBMW320 = new FactoryBMW320();
BMW320 bmw320 = factoryBMW320.createBMW();
FactoryBMW523 factoryBMW523 = new FactoryBMW523();
BMW523 bmw523 = factoryBMW523.createBMW();
}
工厂方法模式的优缺点:
- 优点
- 符合开发-封闭原则: 新增产品时只需要添加新的具体工厂类和产品类, 无需修改现有代码, 符合开放-封闭原则。
- 遵循单一职责原则: 每个具体工厂类负责创建特定类型的产品, 符合单一职责原则, 使得系统更加模块化、清晰。
- 缺点
- 类的个数增加: 使用工厂方法模式会导致类的数量增加, 每个具体产品都需要对应一个具体工厂,这可能使得类的数量相对较多。
- 不同的工厂类之间代码重复: 如果多个具体工厂类之间有相似的实现,可能导致代码的重复。在这种情况下,可以考虑使用抽象工厂模式来减少重复代码。
1.3 抽象工厂模式
在介绍抽象工厂模式前,我们先厘清两个概念:
- 产品等级结构: 同一类型的产品
- 产品族: 同一品牌的不同产品就构成了一个产品族
横构图
竖构图
- 产品类: 现在生产发动机A、B和空调A、B这四类产品
//发动机产品接口
public interface Engine {
void create();
}
public class EngineA implements Engine{
public void create() {
System.out.println("制造-->EngineA");
}
}
public class EngineB implements Engine{
public void create() {
System.out.println("制造-->EngineB");
}
}
//空调产品接口
public interface Aircondition {
void create();
}
public class AirconditionA implements Aircondition{
public void create() {
System.out.println("制造-->AirconditionA");
}
}
public class AirconditionB implements Aircondition{
public void create() {
System.out.println("制造-->AirconditionB");
}
}
- 工厂类: 工厂接口类、工厂实现类
public interface Factory {
//制造发动机
public Engine createEngine();
//制造空调
public Aircondition createAircondition();
}
//为宝马320系列生产配件
public class FactoryBMW320 implements Factory {
@Override
public Engine createEngine() {
return new EngineA();
}
@Override
public Aircondition createAircondition() {
return new AirconditionA();
}
}
//宝马523系列
public class FactoryBMW523 implements Factory {
@Override
public Engine createEngine() {
return new EngineB();
}
@Override
public Aircondition createAircondition() {
return new AirconditionB();
}
}
- 生产者
public class Customer {
public static void main(String[] args){
//生产宝马320系列配件
FactoryBMW320 factoryBMW320 = new FactoryBMW320();
factoryBMW320.createEngine();
factoryBMW320.createAircondition();
//生产宝马523系列配件
FactoryBMW523 factoryBMW523 = new FactoryBMW523();
factoryBMW523.createEngine();
factoryBMW523.createAircondition();
}
}
抽象工厂模式的缺点: 拓展一个产品等级很麻烦
1.3.1 扩展一个产品族
扩展一个产品族很简单, 例如新增一个BMW118的工厂, 只需再新增C类发动机和C类空调的实现类即可(新增一个产品族不需要修改原来的代码), 符合OCP原则
1.3.2 扩展一个产品等级
扩展一个产品等级结构是非常麻烦的, 除了新增产品接口、产品实现类以外, 你还需要修改原来的代码(工厂接口、每一个工厂实现类)
淡黄色
为新增的接口、实现类红色
对原代码的修改
1.4 工厂方法模式和抽象工厂模式的区别
- 适用场景不同
- 工厂方法模式适用于单一产品等级结构, 一个工厂只创建一个具体产品
- 抽象工厂模式 适用于多个产品等级结构, 一个工厂创建一整个产品族
- 开发封闭原则
- 工厂方法模式对工厂的扩展是开放的,对于产品等级结构的扩展是封闭的
- 抽象工厂模式的扩展既对产品等级结构开放,也对产品族的扩展开放。
2.单例模式
单例模式可以确保系统中某个类只有一个实例
单例模式的优点在于:
- 系统中只存在一个共用的实例对象, 无需频繁创建和销毁对象, 节约了系统资源, 提供了系统的性能
- 可以严格控制用户怎么样以及何时访问单例对象
2.1 懒汉式
2.1.1 简单的懒汉式
//懒汉式单例类.在第一次调用的时候实例化自己
public class Singleton {
private Singleton() {
}
private static Singleton single=null;
//静态工厂方法
public static Singleton getInstance() {
if (single == null) {
single = new Singleton();
}
return single;
}
}
存在的问题: 当多个线程同时调用getInstance()方法时, 可能会导致创建多个实例, 这是由于在多线程环境下, 多个线程都通过了single==null
的检查, 然后同时创建了实例
2.1.2 线程安全的懒汉式
通过加同步机制来解决线程安全问题
public class Singleton {
private Singleton() {
}
private static Singleton single=null;
//静态工厂方法
public static synchronized Singleton getInstance() {
if (single == null) {
single = new Singleton();
}
return single;
}
}
存在的问题:
- 性能问题: 整个getInstance()方法都加上了
synchronized
关键字, 这意味着每次调用都会导致线程的阻塞和同步,影响性能。 - 不必要的同步: 一旦实例被创建,后续的调用都不需要再进入同步块,但由于整个方法都被同步,会导致不必要的同步开销。
2.1.3 完美的懒汉式
//懒汉式单例类.在第一次调用的时候实例化自己
public class Singleton {
private Singleton() {
}
private volatile static Singleton singleton=null;
public static Singleton getInstance() {
if (singleton == null) {
synchronized (Singleton.class) {
if (singleton == null) {
singleton = new Singleton();
}
}
}
return singleton;
}
}
问题一: 为什么 getInstance() 方法内需要使用两个if (singleton == null) 进行判断呢?
在getInstance()方法中使用两个if (singleton == null)的目的是为了减少进入同步块的次数,提高性能。
- 第一个if (singleton == null)是在没有加锁的情况下检查实例是否为null。如果实例已经被创建,就直接返回实例,避免了进入同步块的开销。
- 只有当实例为null时,才进入同步块。在同步块内,再次检查if (singleton == null)是为了确保在当前线程获得锁的同时,其他线程没有在此期间已经创建了实例。如果其他线程已经创建了实例,当前线程就不需要再次创建,直接返回已经存在的实例。
这两个if语句的组合保证了在多线程环境下,只有一个线程能够进入同步块并创建实例,其他线程则会在第一个if语句处被阻塞,直到实例被成功创建。这样就保证了懒加载的同时,保证了线程安全性。
问题二: volatile关键字的作用?
假设在不使用 volatile 的情况下,两个线程A、B,都是第一次调用该单例方法,线程A先执行 singleton = new Singleton(),但由于构造方法不是一个原子操作,编译后会生成多条字节码指令,由于 JAVA的 指令重排序,可能会先执行 singleton 的赋值操作,该操作实际只是在内存中开辟一片存储对象的区域后直接返回内存的引用,之后 singleton 便不为空了,但是实际的初始化操作却还没有执行。如果此时线程B进入,就会拿到一个不为空的但是没有完成初始化的singleton 对象,所以需要加入volatile关键字,禁止指令重排序优化,从而安全的实现单例。
2.2 饿汉式
//饿汉式单例类.在类初始化时,已经自行实例化
public class Singleton {
private Singleton() {
}
private static final Singleton single = new Singleton();
//静态工厂方法
public static Singleton getInstance() {
return single;
}
}
2.3 饿汉式和懒汉式的区别
- 初始化时机和首次调用
- 饿汉式是在类加载时,就将单例初始化完成,保证获取实例的时候,单例是已经存在的了。所以在第一次调用时速度也会更快,因为其资源已经初始化完成。
- 懒汉式会延迟加载,只有在首次调用时才会实例化单例,如果初始化所需要的工作比较多,那么首次访问性能上会有些延迟,不过之后就和饿汉式一样了。
- 线程安全方面
饿汉式天生就是线程安全的,可以直接用于多线程而不会出现问题,懒汉式本身是非线程安全的,需要通过额外的机制保证线程安全
3.策略模式
策略模式(Strategy Pattern)是一种行为型设计模式,它定义了一系列的算法,将每个算法封装起来,并且使它们可以互换。策略模式允许客户端在运行时选择算法的具体实现。
主要参与角色包括:
- Context(上下文): 持有一个策略类的引用,负责调用具体的策略类。通常上下文对象会接受客户端的请求,并将请求委派给策略对象。
- Strategy(策略): 定义了一个算法接口,所有具体策略类都必须实现这个接口。通常包含一个算法的具体实现。
- ConcreteStrategy(具体策略): 实现了策略接口的具体算法。
具体代码如下:
- 策略接口: 所有具体策略类都实现这个接口
interface PaymentStrategy {
void pay(int amount);
}
- 具体策略: 实现了策略接口的具体算法
class CreditCardPayment implements PaymentStrategy {
@Override
public void pay(int amount) {
System.out.println("Paid with Credit Card: " + amount);
}
}
class PayPalPayment implements PaymentStrategy {
@Override
public void pay(int amount) {
System.out.println("Paid with PayPal: " + amount);
}
}
- 上下文: 持有一个策略类的引用, 并执行其具体算法
class ShoppingCart {
private PaymentStrategy paymentStrategy;
public void setPaymentStrategy(PaymentStrategy paymentStrategy) {
this.paymentStrategy = paymentStrategy;
}
public void checkout(int amount) {
paymentStrategy.pay(amount);
}
}
- 客户端代码
public static void main(String[] args) {
ShoppingCart cart = new ShoppingCart();
// 使用 CreditCardPayment
cart.setPaymentStrategy(new CreditCardPayment());
cart.checkout(100);
// 使用 PayPalPayment
cart.setPaymentStrategy(new PayPalPayment());
cart.checkout(150);
}