警惕单例滥用，推荐组合引入

在最近的工程中，发现越来越多的单例的时候，感觉有点多余，在网上搜索了下，发现这应该是单例模式的滥用，这里提出一个观点，引入组合优于引入单例，在此记录一下。

现状描述

在某一个业务模块A中，需要定时从服务器获取文件，解析此文件中的规则并保存起来，对外提供 IsMatch 接口，内部使用规则进行过滤。

业务逻辑很简单，这里有三个子任务：

1. 从服务器获取规则文件
2. 解析规则文件
3. 定时获取

现在的实现是，将这三个子任务包裹成类，这个类以单例的形式，被业务模块A使用。为了正确使用，在启动时，还调用了此单例的 Init 方法来启动查询。

分析

感觉这里的单例没有必要，为了该单例的使用，在启动时，先调用了 Init 函数。距离真正使用到的地方，还比较远。这里更应该用组合的方式使用这个功能，而不是粗暴的用单例方式来引入。

通过 GetInstance 的方式来引用单例，在头文件中没有任何依赖信息，这会隐藏使用者和被使用者之间的依赖关系。

现状2

某一个功能模块中的配置关系，需要转移到配置文件中，读取解析此配置文件的内容，并提供数据获取接口的功能，在本功能模块中也被做成一个单例来使用。

分析

将固定在代码中的配置关系，转移到配置文件中，这个思路是正确的，增加了灵活性，后续配置关系的变动，无需更改代码。但通过单例来解析并提供获取数据接口，感觉是滥用了。原因如下：

1. 这个配置文件的内容本来是从该模块中提取出来，在未来的一段时间内，也就该模块自身会使用，做成单例，反而扩大了可见范围，没必要。

2. 这个功能，以组合方式比单例方式更加明确。模块中有一个成员，它的名字叫做 xx_config ，在具体使用时，才调用相关接口。

小结

如果某个功能只被某个模块使用，推荐使用组合的方式引入功能，而不是单例。