当前位置：首页 > article >正文

设计原则、工厂、单例模式

article 2025/1/21 12:05:17

什么是设计模式

简单来说，设计模式就是很多程序员经过相当长的一段时间的代码实践、踩坑所总结出来的一套解决方案，这个解决方案能让我们少写一些屎山代码，能让我们写出来的代码写出来更加优雅，更加可靠。所以设计模式的好处是显而易见的。
当然，设计模式不仅仅能够让我们写出更好的代码，他还有些好处，

我们在读框架、中间件源码的时候，我们会设计模式，就能够更好的去理清源码的整个逻辑，读起来也会轻松不少。
面试的时候，设计模式还是问的比较多的，所以呢，设计模式学得好，工作少不了。

七大设计原则

单一职责原则 Single ResponsibilityPrinciple

一个类应该只有一个发生变化的原因，否则类应该被拆分；

用我们自己的话来说就是：一个类只负责一项职责、只做一件事情；也就是说要做到代码功能的原子性；比如说我们在
做项目的时候，用户模块里就只处理用户相关的业务，商品服务里就只处理商品相关的业务，这样他们就不会互相影响
了，就解耦开来了。

开闭原则 Open Closed Principle

对扩展开放、对修改关闭

意思就是我们写代码的时候，尽量在已有的代码上做扩展，比如说新增模块，新增方法，而不是去修改别人已经写好的代码。这个估计大家感受很深刻，写代码最痛苦的事情，就是在别人的代码上做迭代了。当然这个原则上是尽量要这样，实际工作中，如果你的需求只要在别人的代码上改动非常少的代码就能实现，那我们也可以不要遵守这个原则了。

里氏替换原则 Liskov SubstitutionPrinciple

子类对象是可以替换程序中父类对象出现的任何地方，并且保证原来的程序逻辑不变以及运行正确

换句话说，就是子类可以扩展父类的功能，但不能去改变父类原有的功能。

接口隔离原则 Interface Segregation Principle

写代码的时候，接口不要写得太臃肿了，我们需要把接口拆分得更小，更专用。

依赖倒置原则 Dependency Inversion Principle

设计代码结构时，高层模块不应依赖低层模块，两者都应该依赖抽象，抽象不应依赖细节，细节应该依赖抽象。

KISS 原则 keep it simple and stupid

保持它的简单和愚蠢。

也就是说我们的代码尽量要写得简单，不要为了炫技来写很多花里胡哨的代码，比如说，一个代码只要几个if else就能解
决了，而且后期几乎不可能再去升级，那这种代码其实就没必要用什么设计模式去做了，这样倒是搞得代码更加复杂
了。所以，咱们写代码，尽量不要用同事不懂的技术来写代码，也不要去重复造轮子，尽量用目前市面上比较成熟的开
源库，也不要做过度优化，把一些简单的代码弄得花里胡哨的。

YAGNI 原则 you ain’t gonna need it

你不需要它。

就是不要去做一些过度设计，比如说公司只用得到MySQL，你为了以后能够支持海量数据，直接把hadoop那套体系搬过来了，各种技术都引入进来，那是完全没有必要的。

DRY 原则 don’t repeat your code

不要写重复的代码。

迪米特法则 law of demeter

他的核心主旨就是一个对象应该对其他对象保持最少的了解，也就是多个类之间尽量不要直接去依赖，如果你非要依赖，那也只能依赖必要的接口。其实也就是为了减少类和类之间的耦合，每个类越独立越好。这个其实就是我们正常开发中用到的策略，直接依赖接口，而不是依赖实现类。

设计模式分类

创建型（5种；处理对象的创建过程；工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式）
结构型（7种；处理类或者对象的组合；适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式）
行为型（11种；对类或对象怎样交互和怎样分配职责进行描述；策略模式、模板方法模式、观察者模式、迭代器模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式）

对应到我们的编码开发过程，其实是一个有先后顺序的递进过程，我们来看一下：

首先，我们要去实现某个功能，肯定会要创建对象是吧，所以像：单例、工厂、建造者、原型都属于怎样去很好的创建对象，主要目的在于将对象的创建与使用分离；
然后，对象创建好了之后，就应该去考虑对象之间关系，如何更好的继承、依赖、组合，那么就衍生了很多结构型的模式，比如：门面、适配器、代理、装饰、组合、享元这些；
最后，前面2步做完了，就到了具体实现，怎样更好的达到目的，使行为更加清晰、效率更高，就是行为型模型要做的事情，比如：策略，责任链、迭代器等等；

工厂模式

工厂（Factory），顾名思义，创建对象实例的生产工厂，以前我们创建对象都是 new Xxx()，如果我们使用工厂模式的话，就可以用它来替代 new 操作，创建实例（对象）；所以当你理解了工厂模式后，以后去 new 对象时就可以考虑还能使用工厂模式达到一样的目的；虽然这样做，可能需要多做一些工作，但会给你系统带来更大的可扩展性和尽量少的修改量（主要是降低耦合）；

工厂模式分为 3 种，包括：简单工厂模式、工厂方法模式、抽象工厂模式，接下来，我们逐一来看；

简单工厂模式

简单工厂模式不属于 GOF 的 23 种经典设计模式，严格来说它应该属于一种编程习惯，这个简单工厂模式只是工厂方法模式的一种特例，所以工厂模式实际上只有工厂方法模式和抽象工厂模式。

简单工厂核心逻辑其实就是这样，将一堆 if else 判断从业务代码中剥离出来，然后塞到一个工厂类中，通过这个工厂来生产出我们想要的产品。这样我们在业务中就不需要关心这种逻辑了，一切都由工厂给我提供，就像你去买一个手机一样，你根本不用关心这个手机是怎么通过流水线生产出来的，就像我们这个代码里，也不用去关心这个上传服务实例是怎么生成的。

工厂方法模式

工厂方法，核心思想是：将对象的创建逻辑下沉到子类里面（创建多个子工厂来创建对象）。

这种方式如果再要增加第三方上传服务时，就不需要修改工厂类的代码了，每个第三方服务都会有一个工厂，这样就解决了简单工厂模式的缺点，不过要相应地增加工厂类；工厂方法模式是简单工厂模式的进一步抽象，运用了多态性、克服了简单工厂模式的缺点。

优点：获取对象时只需要知道具体工厂的名称，就可以得到对应的对象，无须知道具体创建过程；在系统增加新的类时只需要添加对应的具体工厂类，无须对原工厂进行任何修改，满足开闭原则；
缺点：每增加一个类就要增加一个对应的具体工厂类，增加了系统的复杂度；
抽象工厂模式

抽象工厂模式，直接通过案例分析：

定义了两个接口：ThirdPartyPush 和ThirdPartySMS，它们分别代表了第三方推送和短信服务。
创建了两个具体的类TencentThirdPartyPush 和TencentThirdPartySMS，它们实现了 ThirdPartyPush和 ThirdPartySMS 接口，分别表示腾讯的推送短信服务。
创建了另外两个具体的类，AliThirdPartyPush 和AliThirdPartySMS，它们也实现了 ThirdPartyPush 和ThirdPartySMS 接口，分别表示阿里的推送和短信服务。
定义了一个抽象工厂类 ThirdPartyTotalFactory，它包含两个抽象方法 createPusher 和 createSmser，用于创建不同厂商的推送服务和短信服务。
创建了具体的工厂类 AliFactory 和 TencentFactory，它们分别继承了 ThirdPartyTotalFactory 并实现了工厂类的抽象方法。AliFactory 用于创建阿里厂商的推送和短信服务，而 TencentFactory 用于创建腾讯厂商的推送和短信服务。使用抽象工厂模式创建不同厂商的推送和短信服务，并通过工厂方法将它们与具体的厂商实现解耦。这有助于现松耦合和易维护的代码结构。

public interface ThirdPartyPush {
      	String push();
}
public interface ThirdPartySMS {
		String send();
}
public class TencentThirdPartyPush implements ThirdPartyPush {
	@Override
	public String push() {
		return "腾讯推送";
	}
}
public class TencentThirdPartySMS implements ThirdPartySMS {
	@Override
	public String send() {
		return "腾讯短信发送";
	}
}
public class AliThirdPartyPush implements ThirdPartyPush {
	@Override
	public String push() {
		return "阿里推送";
	}
}
public class AliThirdPartySMS implements ThirdPartySMS {
	@Override
	public String send() {
		return "阿里短信发送";
	}
}
public abstract class ThirdPartyTotalFactory {
	abstract ThirdPartyPush createPusher();
	abstract ThirdPartySMS createSmser();
}
public class AliFactory extends ThirdPartyTotalFactory {
	@Override
	ThirdPartyPush createPusher() {
		return new AliThirdPartyPush();
}
	@Override
	ThirdPartySMS createSmser() {
		return new AliThirdPartySMS();
	}
}
public class TencentFactory extends ThirdPartyTotalFactory {
	@Override
	ThirdPartyPush createPusher() {
	return new TencentThirdPartyPush();
}
	@Override
	ThirdPartySMS createSmser() {
	return new TencentThirdPartySMS();
	}
}

单例设计模式（Singleton Design Pattern）

理解起来非常简单。就是不管在任何情况下，一个类只能有一个对象。

饿汉式

这种方式在类加载的时候就把服务实例初始化好了，所以这一步其实是线程安全的，不会说在多线程的环境下创建出很多个实例了。这种方式在对象类加载的时候就实例化了，所以其实有可能会造成一个问题，就是内存浪费，因为你不确定这个对象会不会使用，所以就会有一个懒汉式的模式，这个模式可以让我们在需要发短信的时候才创建这个实例对象，而不是一开始类加载的时候就创建。但是这个问题其实也不是问题，因为我们在项目中写代码，一定是有我们自己的考量的。当写了一个发送短信的服务
后，不可能说这个服务以后都不会调用的。而且，假设这种实例占用内存太多，那我们最好是能够在启动的时候就创建好，这样假如说有OOM的这种问题，我们也能及时发现，就是有问题我们要及时暴露出来，不要等到项目上线了才暴露出问题来，那样就很严重了。

public class SendSmsServiceHungrySingleton {
private static final SendSmsServiceHungrySingleton instance = newSendSmsServiceHungrySingleton();
private SendSmsServiceHungrySingleton() {}
	public static SendSmsServiceHungrySingleton getInstance() {
		return instance;
	}
	public String sendSms() {
		System.out.println("发送短信");
		return "OK";
	}
}

懒汉式

饿汉式是比较饥饿，它立马就要拿到这个对象实例；懒汉，就是比较懒，它要等到调用的时候才创建对象实例。这里就是直接在 getInstance 方法里面判断一下，这个实例有没有初始化，没有的话，我就初始化一下，已经初始化了就直接返回。

public class PushServiceLazySingleton {
	private static PushServiceLazySingleton instance;
	private PushServiceLazySingleton() {}
	public static PushServiceLazySingleton getInstance() {
		if(instance == null) {
		instance = new PushServiceLazySingleton();
		}
	return instance;
	}
}

这种方式实现起来还是比较简单的，代码逻辑很清晰。但是，这种方式其实在多线程的环境下是有问题的，它完全没办法保证我的项目里只会创建一个instance对象。

双重检查锁
所以，我们引入一个新的解决方案，就是双重检查锁。这个锁什么意思，我们看代码就清楚了。

public class PushServiceLazyDoubleCheckSingleton {
	private static PushServiceLazyDoubleCheckSingleton instance;
	private PushServiceLazyDoubleCheckSingleton() {}
	public static PushServiceLazyDoubleCheckSingleton getInstance() {
		// 1. 第一次检查 instance 是否已经实例化
			if(instance == null) {
			synchronized(PushServiceLazyDoubleCheckSingleton.class) {
   			// 2. 第二次检查 instance 是否已经实例化
				if(instance == null) {
					instance = new PushServiceLazyDoubleCheckSingleton();
				}
			}
		}
			return instance;
	}
}

这种情况下，其实还是有问题的，在一些极端的场景下，可能会有一个指令重排的问题。

静态内部类

还可以采用静态内部类的方式同样也是利用了类的加载机制，它与饿汉模式不同的是，它是在内部类里面去创建对象实例。这样的话，只要应用中不使用内部类，JVM就不会去加载这个单例类，也就不会创建单例对象，从而实现懒汉式的延迟加载。也就是说这种方式可以同时保证延迟加载和线程安全。

public class LazyStaticInnerClassSingleton {
		private LazyStaticInnerClassSingleton(){
		//解决反射破坏，因为反射可以调用私有的构造器
			if(LazyHolder.INSTANCE != null){
			throw new RuntimeException("不允许非法访问");
		}
	}
public static LazyStaticInnerClassSingleton getInstance(){
		return LazyHolder.INSTANCE;
}
	private static class LazyHolder{
private static final LazyStaticInnerClassSingleton INSTANCE = new LazyStaticInnerClassSingleton();
	}
}

注册式

枚举单例

枚举类实现单例模式是极力推荐的单例实现模式，因为枚举是线程安全的，并且只会装载一次，枚举类是所有单例类实现中唯一不会被破坏的单例模式（解决了反射与序列化破坏）

public enum SendServiceEnum {
INSTANCE;
	public static SendServiceEnum getInstance(){
		return INSTANCE;
	}
	public String send() {
		System.out.println("发送短信");
		return "OK";
	}
}

容器式单例

public final class ContainerSingleton {
private ContainerSingleton() {}
private static final ConcurrentHashMap<String, Object> instanceMap = new ConcurrentHashMap<>();
public static <T> T get(String key,Supplier<T> supplier) {
T instance = null;
if(!instanceMap.contains(key)) {
synchronized(ContainerSingleton.class) {
if(!instanceMap.contains(key)){
	instance = supplier.get();
	instanceMap.put(key,
	instance);
}else {
	instance = (T)
	instanceMap.get(key);
}
return instance;
}
}else {
return (T) instanceMap.get(key);
}
}
}