08-11-16

今天与人讨论， 看见如下构造：

Singleton* s = Singleton::getInstancePtr();

初看觉得很不对劲。 但哪不对劲呢？

我们慢慢学会了
把所有的data member的访问权限由public改为private
把所有的data member替换成一个 pimpl
对继承带有实现的类的态度由理所当然变为谨慎
由基于对象编程， 到基于接口编程
……

这一切都是为了不对客户暴露实现细节， 从而更容易改动实现细节。

甚至对函数命名， 也分外考究。
比如即使是采用了lazy evaluation，也要不采用：

string::calc_length

而是

string::get_length // 或者 string::length

嗯，getInstancePtr的问题就在这里， 它过于明显的暴露了实现细节。
客户将依赖函数返回指针的行为， 从而无法修改这一实现细节。

所以， 应该使用getInstance。
在需要修改实现细节的时候， 就可以 ……
就可以 ……
大规模的替换客户端代码吧 囧……

嗯， 其实我想说的是， 虽然刚看到getInstancePtr的感觉是怪怪的。
但稍加分析后， 其实他挺好~~

这个函数的返回值本来就不可避免的暴露了实现。
引用or指针， 一旦决定就不能回头， 没有修改实现的机会。

getInstance 还需要查看文档，到底是返回引用还是指针。
getInstancePtr 就说的明明白白。
getInstanceRef 好像也不错 …… 不过没有getInstance简洁 ……

以后打算（如果还有机会自己做Singleton的话）：
getInstancePtr 总返回指针、与引用区分开。
getInstanceRef 就可以简洁一点的命名为getInstance。

这也比较符合另外两种语言的习惯 —— 毕竟这是个C++特有的问题。
其他两种语言中getInstance的语意就相当于C++中的getInstanceRef。