基础知识: 需求!

potian你从他ajoo 所举的例子 你觉得他一直想要表达的观点是我最后发的帖子所表达的意思嘛？？
我也一直很胡涂他ajoo提出静态工厂的最终目的以及利益！
potian

问题是如果是singleton变为非singleton，虽然构造方式不变。但是client使用对象的方式必然要改变。而client使用对象的方式，其实就是singleton这个类所实现的接口。重构以后的对象中添加了状态，这种状态必须能够为client所区分，否则仍然保持singlton好了。
如果还能按照singlton的方式来处理非singlton的对象，那或者是本来建模成singlton就是错误的，或者现在就不必做成singleton.
我觉得ajoo需要找一个从singlton到非singlton的实例，不是那个cache(那个我看起来好像仍然是个singlton)，讨论起来就容易一些。

我的意思是说，ajoo提出的观点是有前提的

但在某些情况下是不必要的，而ajoo的例子属于我讲的不必要（因为可以重构new的行为，而不需要重构对象构造的方式），ajoo的singlton例子也一样不必要，因为只需要改变计算结果的得到这种内部行为，而不是对象构造的方式

hehe，才找到你的那个总结帖子。这里眼花缭乱的，确实应该结帖了。
不过，我觉得那个前提也不太可靠，或者说不是ajoo心里的那个前提。因为从singlton到非singlton的变化已经不满足这个前提了。从非singlton到singlton倒是有时候可以满足。
从多到少，有内部利益存在；从少到多，内部利益受损，如果没有外部的利益的增加，那么肯定有点问题。

明确了前提、适用和不适用场合，大家是不是选择这种做法时就可以根据自己的经验进行判断了

不对，这个属于外部要关心的事情了，

有些情况下，这也可能不是外部所需要了解的。

例如这个类性质决定它内部就是singleton就可以了（例如，本身就是无状态的），所以我即使改成非singleton也没有关系，那时我内部的决策

至于从非singleton到singleton，ajoo回答过了，外部可以再包装的,new在这里没优势

ajoo在abp上的发言：



感觉和firebody前面的总结挺像的。ajoo再澄清一下观点就可以开杀了。

关于ajoo那个例子我的理解是重构后的calc没有保留一个static的cache，而是每个返回出去的对象都有一个自己的cache，这样有利于gc等（如果static的cache也会被gc的话我的理解就错了）。

这样做，对原先的使用没有逻辑上的影响，不过确实可能造成一定的性能影响（有好的也有坏的）。而这个修改，ajoo也说了，是因为计算太花时间，重复计算不划算，那看来外界是有需求的，也就是，无论现在的外部代码还是将来的外部代码，都会做一些重复的计算，但很少一个劲地取用instance函数导致对象过多。

在这里，如果真的存在外部代码一个劲地instance，我觉得就破坏了ajoo的前提：透明性，似乎外部知道里面singleton了似的。外界应该自己保存一个引用，而不是一天到晚instance。其实你按照要求作出来了个类，满足了要求，然后我也可以做cache，不比你在类里面做。前面有很多关于在何处做优化这一决策的类似的版本。

但是在外部做优化的时候：以前的版本使用出了问题，然后自己去做cache了，然后对这个calc的使用高一段路。过了一段时间ajoo又在内部做了cache，这样，新代码就不必再在外部cache了，而且在对性能影响不大的情况下，老代码也不必修改。但新的instance的specification似乎又必须加上一个cache的包袱。

但是为什么要改成非singleton呢？一个singlton要改成非singlton,肯定要有点好处。如果该成非singlton之后效果一样（接口不变，client的使用方式不变），我怀疑这个决策就是不合理的。或者说，不存在这样一种需要倒改回去的场景。

不理解，为什么要每个对象自己搞一个cache，为了节省内存？一个大的cache搞定应该可以了吧。那样，也不用唠烦gc了。
因为每次根据给定的i,计算得到的值都是一样的，那么多cache没有区别。如果说根据相同的i,不同的对象的calc方法可以得到不同的结果，那我认为这个自带cache的做法还有点意思。