标签：... IdGenerator 有何 getId long 单例 设计模式 public

单例存在哪些问题

大部分情况下，我们在项目中使用单例，都是用它来表示一些全局唯一类，比如配置信息、连接池类、ID生成器类。单例模式书写简洁、使用方便，在代码中，我们不需要创建对象，直接通过类似IdGenerator.getInstance().getId()这样的方法来调用就可以了。但是，这种使用方式有点类似硬编码，会带来很大问题。

单例对OOP特性的支持不太友好

我们知道，OOP的四大特性是封装、抽象、继承、多态。单例这种设计模式对其中的抽象、继承、多态都支持得不好。为什么这么说呢？我们还是通过IdGenerator这个例子来精简：

public class Order {
	public void create(...) {
		//...
		long id = IdGenerator.getInstance().getId();
		//...
	}
}

public class User {
	public void create(...) {
		// ...
		long id = IdGenerator.getInstance().getId();
		//...
	}
}

IdGenerator的使用方式违背了基于接口而非实现的设计原则，也就违背了广义上理解的OOP的抽象特性。如果未来某一天，我们希望针对不同的业务采用不同的ID生成算法。比如，订单ID和用户ID采用不同弄的ID生成器来生成。为了应对这个需求变化，我们需要修改所有用到IdGenerator类的地方，这样代码的改动就会比较大。

public class Order {
	 public void create(...) {
		//...
		long id = IdGenerator.getInstance().getId();
		// 需要将上面一行代码，替换为下面一行代码
		long id = OrderIdGenerator.getIntance().getId();
		//...
	 }
}

public class User {
	public void create(...) {
		// ...
		long id = IdGenerator.getInstance().getId();
		// 需要将上面一行代码，替换为下面一行代码
		long id = UserIdGenerator.getIntance().getId();
	}
}

除此之外，单例对继承、多态特性的支持也不友好。从理论上来讲，单例类也可以被继承、也可以实现多态，只是实现起来会非常奇怪，导致代码的可读性变差。不明白设计意图的人，看到这样的设计，会觉得莫名其妙。所以，一旦你选择将某个类设计成单例类，也就意味着放弃了继承和多态这两个特性，也就相当于损失了可以应对未来需求变化的扩展性。

单例会隐藏类之间的依赖关系

标签：...,IdGenerator,有何,getId,long,单例,设计模式,public
来源： https://blog.csdn.net/zhizhengguan/article/details/122278533

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。