基础知识: 需求!

如果从开发过程来看，这个说法并不牢靠，不仅仅涉及到重构。
以之前那个被重构成Singlton的例子为例。假设类名为X,重构前不是Singlton,那么有两种情况：
1 本身它就是一个Singlton，最初设计的时候没发现。
2 本身它不是一个Singlton，但是通过将外部状态抽取后变成Singlton
3 它是一个共享的对象。不同的调用者之间可以相互影响。


如果仅仅是重构，那么只是第一种情况。
第二种情况，重要的步骤是外部状态的抽取，这个恐怕连instance()的签名都要变。
第三种情况不予讨论。因为每次instance的时候虽然得到同一个对象，但其状态可能是不同的。对于调用者对象而言，其动态交互是一个非常艰难的设计。而且，如果重构后的设计正确，那么最初的设计是错误的，两个设计语义上根本不同。

那么，看来优势只在于第一种情况，那有多大的用处？

你这个分析得条理很清晰。 我很赞同。只有第一个场景是合适的。
然后，结果就归结为： 有多大用处。 和oz, cat又胜利会师了。
我前面已经说过了， 是否有用处取决于具体的类的设计者。

其实， 重构成singleton是一个重构， 从singleton重构成非singleton也是一个。这个情况我想应该更为常见。比如：开始的时候我的类X很简单， 没有状态， 所以为了效率优化， 我选择了singleton。 也许某天重构的时候我发现加入一个状态也许更好， 此时， 再用singleton就不行了。但是因为有instance()函数，我就可以自由地把singleton去掉。外界可以保持一无所知。


而且， 看了我给的那个连接了吗？ 还有我举的Hello的那个重构的例子。透明的singleton只是好处中的一种， 还有其它几个呢。

我现在总结的你们能够逻辑上成立的反对理由， 一个是你的黑狗非狗说， 另一个就是oz, cat他们的“实用”说。

等我把readonly同学说服， 再来分辩你们现在的两个逻辑上成立的反驳。

其实我要是在最初就直接说出对ajoo这个问题的实用性的质疑情况可能就不会成为现在的样子，大概是我决定ajoo是老熟人，而他一向喜欢质疑别人的实用性，所以就没有那么直接的说出来。不过我想大家攻击cat，而放过我，并不是因为cat来自abp，而仅仅是cat更好攻击，我这个人出名的是个犟头，大家不到万不得已不会出来和我发生冲突。而工程学派的一个特征就是经验主义的，这没有什么好争论，也没有什么好非议。
而说到效率问题我想问题绝对不是ajoo说的仅仅是一点点地栈中的数据的问题，这和java的vm是基于栈而不是寄存器是有关联的。我还没有考虑清楚这个问题，只能凭着想象说几句。首先一个方法肯定不仅仅只是数据，还包括方法运行的命令。这些命令我想不会享受到jit优化的好处。如果你的一个类对象是经常性的被装入，不管你使用什么方法，效率都是问题，毕竟对象的装入是最耗费资源的问题。也就是我的观点在效率上说ajoo的做法没有什么优势，也没有太多的劣势。大概曹晓刚会把这个问题解释清楚，但愿他有时间。
最后请ajoo即使要和cat单挑，也最好在javaeye这边，毕竟有上下文的关联，而至少我对这个问题也是很有兴趣的。

本来已经打算退出，但是看到ajoo对我的一番批评，我觉得还是有必要出来说几句话。

ajoo说道：

针对你的说法，我回去浏览了一遍我的帖子，确实有ajoo所提到的问题，我本人在这个问题的讨论上很毛躁，可能确实是不善于接纳不同观点吧！或者不善于辩论，胡扯蛮缠一类的动物就是我！我的性格也是比较急躁！这个我会好好深刻反省的！
站在对手的角度思考问题，按照对手的思维方式思维!
这点我要好好学学！老是按照自己的思维确实没办法辩论下去，我觉得这是我们之间进行交流确实存在的一个很大的弊病。在javaeye论坛如此，在csdn更如此。
对于ajoo的观点：
我提出了实际确定“透明”概念的疑问。
另外，如果真像ajoo所说的出于各种产生对象前实施必要的行为 并且 这个行为 必须对外透明 的这个概念。如果真的需要这样的话，ajoo的方法确实是我们需要采纳的方法，new()与静态工厂函数的区别还是有根本的区别的：
1）语义来看，new 与 静态函数不是一个级别的概念
2）静态函数能够融合更多逻辑进来以进行对象产生前的处理。而new如果要融合这些逻辑进来的话，就破坏了类的内聚性。


最后，再次为我的毛躁而感到惭愧！其实一开始的辩论就不是 围绕bean与否的观点，而是围绕 非bean的对象的 有效产生方式

其实就我的吵架经验，网上的误解出现的频率比真正的问题讨论要多得多。 没有误解，一上来双方就直奔正题，三言两语结束战斗的情况是凤毛麟角。

而大家其实都多少有点自我中心。我也是，看到别人长篇大论的反驳总是不是很耐烦看。

总是喜欢就着自己的思路来讨论问题并且希望别人也照着这个思路来。

所以：“你为什么不正面回答问题？yes还是no?”的这种情况常有。

不过，吵架多了， 如果本来的目的还是为了分辨问题，那么就不得不讲点技巧。
我总结下来的一个技巧就是：
1。忽略枝节问题。
2。找到对方主要论点。
3。最重要的，不要先争辩，批驳。尽量客观地复述一遍，让对方认可。这样，还有一个好处是：先抓住对方的小辫子。不会出现回头你看似获胜，对方马上转移重点，声东击西。

所以， firebody，你的人是不错的。勇于认错，我觉得这个品质相当可贵。所谓“毛躁”，不过还是辩论的经验不够罢了。这里的人的工程经验丰富，说道辩论经验，呵呵， 也不见得如何了。工程也许不需要严谨的逻辑，但是辩论没有严谨的逻辑就根本不可能进行下去。

这次辩论还有一点是我没有控制好的， 就是上来是我和readonly的辩论。readonly喜欢嘻笑怒骂的风格， 而我这个人向来喜欢以彼之道还施彼身。 本来我们两个都不当真，也没什么。但是后来加入了几个人，加上都有点搞不清问题就下结论这个毛病，我这个嘻笑怒骂的风格就惯性下去了。于是双方话里面的调味料逐渐增多，最后就吵了起来。

争论是谁先推了谁一下是幼稚的小孩子行为。下次大家还是引以为戒吧。

我现在的任务：
1。解决readonly提出的效率问题。
2。然后回来说黑狗非狗的认识论问题。
3。最麻烦的就是这个“实用”论。oz这些家伙狡猾呀。除了我给出的那些优点和几个自己造出来的Hello的例子， 我得花时间想想怎么证明它足够实用。
这可不是简单地证明它可用。难度大大地！

ajoo，这只是你个人看法而已

你总是不由自主地在每个贴子上喜欢加上一些评论人的话，你很喜欢那大帽子扣人，并且基本上是不假思索的，每次针对别人的人身进行一些描述，说别人是如何如何的人，你可以看看我的贴子，除了极少数的情况外，很少评论对方的人是XXX,YYYY等等，

现在这个贴子也算是我对你的看法，说错的地方请你见谅。


我从一开始到现在就没有理解错你的意思，虽然没有完全理解你的透明是什么意思，但争论总是欲辨欲明的，并且是双方的，我不相信你一开始就100%理解了我的观点，你所有针对别人的说法，对你自己也是适合的，所以你责人也严，求己也宽

在这个贴子里面，我根本就不想做出任何实用性的评价，因为实用性根本就不需要评价。这个贴子远远超出了javaeye所有贴子的长度，是因为按理来说，这样毫无实际意义的贴子是不会引起javaeye人任何兴趣的，所有Javaeye里面地人都知道这样的做法在实际中会有什么后果，不需要potian，也不需要ajoo来做说明。之所以我愿意到讨论下去的原因是因为我试图按照你的方式来讨论这个问题，我不知道你有没有从实用的角度来考虑过问题。现在我觉得我再也没有能力这样做下去了，并且时间确实有限。

我的观点自始至终都没有变过，你可以看看firebody一开始引用我的话，如果要我来作总结性的陈述，我还是一开始的那段话。

闲话不说， potian。
1。到底这个问题是谁在批评谁？在你出来批评一个人的观点时候， 是别人有责任先弄清楚你批评的到底是什么呢？还是你有责任先弄清楚批评的观点是什么呢？
我确实很长时间没有明白你批评的是什么，这我在开始就一直承认：“说实话，我不是很明白potian到底想说什么”。所以我始终在试图表达明白我的观点以避免误会。后来在这一切无效之后，我才主动采用了我的复述你的观点的策略。
那么，我想让旁观的诸位给个公正的评价，我到底应该怎样才能做得更好？
所谓越辩越明是不错的，这我前面也说过了。但是我不会在自己还没有别人的意思的时候就猛批一顿，然后在别人解释：“不，你误会了，不是那个意思”的时候，让别人读本名著，然后自己闪身就走。

2。你说你一开始就明白我的论点。那么，你后来还在连篇累牍地拿出一个内部实现逻辑对外界不透明的工厂作靶子批判是何用意呢？觉得那是一个软柿子，好捏？你早告诉我，我跟你一起批判。打落水狗，容易得很。

我一直在证明所谓的透明就等于不存在，你回过头看看我的贴子，不管我怎么绕，还是为了这个目的。

potian
我感觉如果要讨论静态工厂替代new方式的话，不大应该按照bean那一类的优点来讨论这个做法啦！
其实实际应用中有确实有一些不算是bean类的辅助类（不需要发布，只是针对特定应用实现的类，不如Helper,Util之类的），如果这些类的产生需要特定方式，那确实应该有用静态工厂来代替构造函数的可能性，因为它有构造函数所不具有的优点。
其实，如果要讨论这个争论的焦点，我们首先需要把讨论的对象范围大大缩小，而不是整体的把整个OO概念囊括进来，把它们作为一些特殊的类来考虑，然后再接着争论到底是用 new ctor(),还是 insance好！这样的讨论，才不至于发散开来。

啊。刚才还在说你开始不是很清楚我的“透明”的含义。现在又说你一直都在证明“透明”的不存在。好象从来没有过误解一样。