设计模式精读 ~ 全局变量的替代者 ~ 单件（下）
所属文章系列：寻找尘封的银弹：设计模式精读
温馨提升：接上文。
【意义】
一、何时必须做成单件：
当系统中有共享数据、共享资源或通用接口被多处代码调用时，必须做成单件。例如系统需要一个打印机服务，该服务一边协调多个打印请求，一边协调多台打印机的状态。再如系统需要一个网络服务，该服务一边协调多个网络请求，一边协调WIFI连接、蜂窝电话连接还是网卡连接，甚至也有多网卡的情况。负载均衡是另外一个更高层一点的例子。
如果你所在的团队因为“它们算不算共享数据”而各执一词，那就不是在实现层能解决的问题了，而必须到“隐喻”层中去寻找答案，否则只能沦为意气之争。
有一种常见的用错单件的情况：
有多处客户代码使用一个单件，但每处客户代码都把单件当成了工具类，工具类就意味着无状态，而状态处理全放到了客户代码中。如此一来，协调多个客户请求、协调系统资源的职责，完全放到了客户代码中。在这种情况下，改一个bug就需要举一反三，即改动所有客户代码中类似的逻辑。但这谈何容易，比如说，在搜什么关键字才能找到客户代码、找哪些用例、每处客户代码的逻辑能不能修改，大部分人都不愿意去做这种费力不讨好的事情。看下面这段代码：
Client1::Handle()
{
Printer *printer = Printer::Instance();
if (printer->state == IDLE)
{
printer->PrintWord(p1, p2);
printer->SetState(RUNNING);
}
}
Client2::Handle()
{
Printer *printer = Printer::Instance();
if (printer->state == IDLE)
{
printer->PrintPicture(p3, p4);
printer->SetState(RUNNING);
}
}
真实的代码其实要比这个严重得多：上文提到的两个职责，即一边协调多个请求、一边协调多个资源，在代码中几乎是缺失的。或者说这两个职责在代码中处于模糊状态，也就是说，有的地方有处理，有的地方就没有处理，很明显是没有设计。这绝对是严重bug的一个重要来源！下面的代码居然连状态判断都删掉了，太恐怖了：
Client1::Handle()
{
Printer*printer= Printer::Instance();
printer->PrintWord(p1, p2);
printer->SetState(RUNNING);
}
Client2::Handle()
{
Printer*printer= Printer::Instance();
printer->PrintPicture(p3, p4);
printer->SetState(RUNNING);
}
这里还需要解释一下“通用接口”使用单件的情况：
一个类中并没有任何状态数据、没有任何资源，那么它只是一个全局函数列表而已，用单件的形式给这一系列相关函数做一个包装，让客户代码看到的是一个整体概念，这对代码可读性很较大的帮助。C++中的静态类是可以代替这种单件的，两者之间的区别很小，这里就不展开讨论了。代码示例如下：
classs StringTool
{
public:
StringTool *Instance();
int Truncate(char *str);
int Encode(char *str);
int Decode(char *str);
}
二、但是，为什么我们不用全局变量呢？
单件本质上也可以看作全局概念，但使用全局变量，会污染命名空间，而且多处客户代码随意访问单件，它们都不知道何时、由谁来构造全局变量、会不会构造多份实例，代码写起来会很烧脑且bug多。
三、为什么不用传递参数的方式呢？
如上所言，单件可以通过传递函数参数的方式，来代替下游代码自己使用单件的方式，以使函数更加通用，也就是说更容易被复用。但是，函数的嵌套层次一旦多了，就会让传递单件参数的次要代码，掩盖了主要参数的代码，而且传递起来非常麻烦，我就见过传递层次超过10层的代码。我们看一段代码：
Upstream::Handle()
{ //上游代码
Downstream *ds = new Downstream();
ds->Handle(p1, p2, Singleton::Instance());
}
Downstream::Handle(int p1, char *p2, Singleton *singleton)
{ //下游代码
//下边几行代码把单件继续向下游传递，下游还会向更下游传递
if (p1 == TYPE_1)
{
downstream2->Handle(p1, p2, singleton); //为了传递单件，分散了代码阅读者的注意力，有时会掩盖函数调用的主要涵义
}
...
}
还有一个因素能决定到底该使用传递参数的方式，还是使用单件的方式，这就是单元测试的需要，请参见下文的详细描述。
于是，虽然从概念上来说，它肯定是个单件，但是，在不同的实现架构中，会有很多的考虑侧重。它依赖于现有架构、个人知识、团队共识、创新环境。
【局限】
一、使用单件的代码难于复用
就像前文提到的Application::Instance()那样，虽然代码看起来很简洁，但是它是依赖于外部环境的，一旦环境有变化，例如换成另外一个应用程序，那么他所依赖的那些东西，有时会以令你大吃一惊的方式，瞬间以很多bug的形式出现在你面前。
因为代码绝不是简简单单地依赖于那个接口，还有接口背后的那个“人文契约”！
例如接口如下：
Application::Instance()
Application::HandleMessage(p1, p2)
Application::Notification(p1)
...
当代码通过Application::Instance()获得单件后，它会使用该单件，或者把该单件传递到它的下游代码，形成一个生态协作链，也就是说，会有很多张UML时序图。这些就是那个“人文契约”！
如果只是接口没有发生变化，而协作过程却发生了变化，那么整个生态系统就有可能被深度影响，影响到底有多大，谁能描述得清楚？这就体现了软件“核心复杂度”，正如《领域驱动设计》一书告诉我们的：要通过领域模型思维去解决的“软件核心复杂度”问题。在这种情况下，接口不变，但接口内的模型变了。
所以，较好的方式是：只依赖于最小的接口，只做最少的假设，签订最小范围的“人文契约”。
具体来说，有单件的代码：下游代码既要知道外部环境（例如单件），又要知道它的上游环境的参数，这就形成了双重依赖。代码举例如下：
Upstream::Handle()
{ //上游代码
Downstream *ds = new Downstream();
ds->Handle(p1, p2);
}
Downstream::Handle(int p1, char *p2)
{ //下游代码
//下边几行代码对上游的参数和单件形成了双重依赖
if (p1 == TYPE_1)
{
Singleton::Instance()->Handle(p2);
}
...
}
而不使用单件，就是单重依赖。例如把原来调用单件的代码换成传递参数的方式，那个参数由上游代码维护，就不会存在下游代码和上游代码共同依赖于一个“水池”的担忧了。代码如下：
Upstream::Handle()
{ //上游代码
Downstream *ds = new Downstream();
Singleton *singleton = new Singleton();
ds->Handle(p1, p2);
}
Downstream::Handle(int p1, char *p2, Singleton *singleton)
{ //下游代码
//下边几行代码只对上游的参数形成单重依赖
if (p1 == TYPE_1)
{
singleton->Handle(p2);
}
...
}
此时，当上游逻辑变化的时候，上游在修改自身逻辑的同时，也要修改上游和下游共同依赖的那个参数，因为那个参数就包括在自身逻辑中。
二、单件不能用于多线程环境
如果让单件裸露在多线程的环境下，简直就是一场灾难，就像在多线程中使用全局变量是一样的效果。此时，需要使用一些策略来保证线程安全，例如加锁（有些语言的框架就支持锁）、加临界区保护（这是操作系统相关的调用）、拷贝数据结构。这些策略都有一定的性能问题，如果不想要这种低性能，还可以使用静态初始化，不过它的缺点是一开始就占用着很少用的内存、初始化顺序的问题（参见下文）。
附：
关于如何在多线程中使用共享数据的问题，可以使用拷贝数据的策略，这个主题较大，我会专门写一篇文章来为你讲解。
【注意事项】
一、多个单件之间的构造顺序问题
如果系统中有多个单件，而多个单件之间又必须按照一个特定的顺序构造，那么就可能产生宕机问题，分为两种情况：
1.使用静态构造的方式：private static Singleton instance = new Singleton();
静态构造的顺序，依赖于编译系统的规则，而这个规则通常难以把握。此时，一不小心就会有异常抛出来，我就遇到过。
2.使用Lazy Load的方式：
Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton();
}
return _instance;
}
Lazy Load顾名思义就是懒惰，只在客户代码需要它交付对象的最终期限前才构造出来，也可以说是拖延症。这是我们最常见的构造方式，但这仍然会有构造顺序问题。代码例子我就不列举了，我也曾遇到过。
建议：把那些不依赖于其他单件的对象，使用静态的方式构造出来，或者在系统初始化的过程中，统一构造出来。后边的Lazy Load调用就很顺畅了。
二、继承问题
由于单件的实现方式是用静态方法，而C++的静态方法无法变成虚函数，这就引出了单件如何继承的问题。《设计模式》一书中提到了三种方式，来实现继承。
1.父类的Instance函数中分别构造不同的子类：缺点是父类依赖子类。
2.父类没有Instance函数，而把它放在子类，而这个子类可以用替换为不同实现的链接文件的方式。
3.使用单件注册表的方式：比较灵活。由于后边的单元测试需要这里的实现代码，因此我把原书中的代码拷贝出来：
class Singleton {
public:
static void Register(const char * name, Singleton *);
static Singleton* Instance();
protected:
static Singleton* Lookup(const char * name);
private:
static Singleton* _instance;
static List *_registry;
}
Singleton* Singleton::Instance() {
if (_instance == 0) {
const char *singletonName = getenv(“SINGLETON”);
// user or environment supplies this at startup
_instance = Lookup(singletonName);
// Lookup returns 0 if there’s no such singleton
}
return _instance;
}
三、效率问题
单件的使用过程中，如下函数经常会被客户代码调用：
Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton();
}
return _instance;
}
有强迫症的程序员，总想去掉这个if，从而达到完美的性能。完成第一次的构造之后，使用替换函数指针的方式，或许可行，有兴趣的读者可以一试。
四、单元测试问题
在做单元测试的时候，你需要把单件替换成一个“自己制作”的假单件，来测试那些待测试类。
我们首先想到的是：在测试代码中，先构造那个单件。不过这不可行，因为只能构造原有代码的单件，而无法用测试代码中的假单件。
我的方法有三个：
1.把单件改成传递参数。
如果我没记错的话，在《测试驱动开发的艺术》一书的93页，讲到过类似方法。代码示例如下：
原始代码：
Client::Handle()
{
Singleton::Instance()->Handle();
...
}
改造后的代码：
Client::Handle(Singleton *singleton)
{
singleton->Handle();
...
}
测试代码：
TestCase:TestHandle()
{
Client *client = new Client();
client->Handle(FakeSingleton::Instance());
...
}
2.把获取单件的代码改造为通过工厂获取。
把获取单件的代码，改为调用一个工厂来获取单件，但是，在测试代码中，一样无法替换为假工厂。所以，需要改造这个工厂，让它的每个接口函数都有一个参数，通过这个参数可以替换为假工厂。原始代码如果不留这个“开点”，就不可能做到替换假单件。代码如下：
Client::Handle()
{
SingletonFactory::Instance()->GetSingleton1()->Handle();
}
TestCase::TestHandle()
{
FakeSingletonFactory *fakeSingletonFactory = new FakeSingletonFactory();
SingletonFactory::Instance()->GetSingleton1(fakeSingletonFactory)->Handle();
}
static SingletonFactory* instance = NULL;
virtual Singleton1* SingletonFactory::GetSingleton1(SingletonFactory* factory = NULL) {
if (NULL != factory) {
return factory->GetSingleton1();//这行代码要求假工厂也必须实现GetSingleton1虚函数
}
return new Singleton1();
}
但是，这个代码显得很笨拙，于是引出了第三个方法。
3.使用注册表来替换为假单件
代码请参见上文的“继承问题”。
作于2018-4-28
