基础知识: 需求!

至少这个前提下是可以用的，至少还可以看出好处，就是可以封装这个变化，

在这个前提下，至少没有前面我们说过的哪些问题

至于这个变化的原因是什么，我们好像不应该讨论，因为我们不讨论实用性

不是讨论静态工厂吗？怎么变成singleton和cache了？singleton和cache跟静态工厂有什么必然关系吗？

charon potian
我觉得如果针对ajoo的几句话铺开来讨论，会又走回前，昨晚讨论的境地！
我觉得这种针对文字观点进行文字辩驳的讨论，在这里很难进行下去，因为每个人对自己的文字观点的理解是不一样的，假设，我写出大大上千字的文字观点总结，然后贴出来，potian，charon你们按照你们的思维逻辑逐字逐句的读了我的回帖，然后又照着自己的理解进行辩驳！最终也是没有什么结果的讨论。

我们就把讨论的基础建立在ajoo已经列举的例子（他认为这个例子已经代表他的观点的意思），然后我们就这个例子修改，阐述我们的观点。
这样的话，我们的讨论就有了一个共同的焦点，这个焦点是源代码，也是大家能清楚辩明而不产生畸意的。

ajoo，potian，charon，ozzzzzz，cat你们觉得呢？

该清楚的东西大家都已经明白了，这个帖子在JavaEye的使命就达到了，至于非要强迫对方接受自己的观点那根本就不可能。ajoo不关心工程实践的可行性问题，所以他极力要证明的观点，对于项目实践来说，可能根本是毫无意义的。

现在我想大部分人已经承认从纯粹逻辑意义的角度上来说，你的观点是有意义的，你现在需要做的是从工程的角度来证明你的观点的可行性。注意，举一个sayHello的例子不能够证明任何实际项目的可行性。我希望你能够列举出来一个你采用该观点指导意义下的成功项目来证明你的观点确实具有实际价值。考虑到你的背景，可以不用列举Java项目案例，可以用c++项目案例。

你要我们接受你的观点，就必须用我们的实证主义思维基础来说服我们，否则你就是再用严密的数学推理，对我们来说，也是毫无意义的。

如果要我将真心话，我觉得这是没有区别的，最好的办法是停止

1。我不认为ajoo已经列举的例子已经代表了他的意思，可能他选的不是太好

2。大家对代码的看法是不同的，譬如那个超类对子类的依赖，两个平行类之间的依赖，你firebody可能觉得象杀猪一样的痛，而potian可能觉得没什么呀，很正常呀，你怎么讨论

交流是要建立在共同经验的基础上的，这个贴子说明了什么？说明了为什么客户的需求为什么一开始不可能被程序员所理解（想象一下我们和ajoo的差别跟用户和我们之间差别的比较），说明文档基本上是没用的，即使这么简单的问题，我们各自用了这么大的篇幅进行讨论和解释，还是无济于事（想象一下用户的业务和我们对OO的理解之间的差别）

部分同意您的观点，我也是有这样的感觉：如果ajoo连自己所选的例子都不能完整代表ajoo他自己的 所要使用他的观点的的 环境 的话！那么我就觉得ajoo他没有考虑他自己的观点的实用性？就像一个空想家在研究纯理论而不知道这个理论所应用的环境一样！（对不起，如果不大妥当，我道歉！）
他举的例子确实不大好！
另外你说的代码理解问题，这确实是一个难题，但是我想，评价一个代码的简介程度，OO的贯彻程度，还是有公论的。
看到两个具体类之间的关联，如果这两个类是稳定，我自然没什么意见◎
但是如果这两个类是依客户需求而变化的，那么我想大家也会公认这是个很差劲的设计。
从这点来说，代码更能表达观点！！

firebody，恐怕大家心里的公论是不一样的

讨论到这里，不知道大家是不是累了，关于这个讨论的一些题外话，我想有必要在这里提一下，以下是我和庄的一个讨论回答。



不单纯是从技术水平上区分帖子，最重要的标准是帖子涉及的内容。本论坛本来面向的群体就是软件开发工作人员群体，项目管理人员群体，甚至到CTO。所以侧重点在于软件开发技术的实际应用。所以我类似readonly的嗡嗡系列，凤舞提出的那个对象引用的热门贴，统统挪到Java编程版，我相信大多数人对这几个帖子的技术水平还是认同的吧，不照样挪吗？标准就是企业应用，而那些被挪的帖子讨论确实深入，但是内容是语言本身的细节。

改版的目的不是针对ajoo，而是意在突出网站在技术上的导向性，也就是要明确区分阅读群体。深度技术讨论区面向企业资深开发人员，项目管理人员，CTO等等。



不是划分学派，归结帮派就结贴，我想你理解错了。那个问题讨论了200多贴了，双方的观点是不是已经明确了？讨论是不是已经清楚了？双方观点是不是已经阐明了？双方都试图说服对方，但是成功了吗？

一个问题讨论到这种程度，该明确的东西都已经明确了，剩下的就是讨论的对方都恨不得按住对方的脑袋，逼对方认可他的观点，放弃自己的观点。难道双方都没有这么尝试过吗？但是又成功了吗？

一个讨论进展到如此地步，已经没有办法在进展下去了。因为该讨论的问题已经都讨论光了，现在就是一个辩论方的心态问题，就是我说的观点，你没有办法反驳，好，没有办法反驳的话，那你必须承认我是对的，你是错的，并且你要放弃你的观点。

这就好比我小时候和别人下象棋，对方已经放弃了，那我已经下赢了，对方中途认输了，但是我不爽，我非要按住他说，不准中途认输。你必须把这盘棋给我下完，不下完你不准走。对方说我认输还不行吗？我说不行，认输也不行，你认输也要下完棋。

那么你认为这盘棋还有下完的必要吗？那么你认为这个讨论还有继续下去的必要吗？

为什么要区分工程派和学术派，为什么要区分javaeye和abp。道理很简单，就是要点醒大家，双方关注点根本就不同，双方的思维方式基础也根本不同。你要说服对方，用你自己的思维方式根本无效，你必须用对方的思维来说服对方。

ajoo你逻辑思维推理再严密，对我无效，如果你不能够从项目实际的可行性上来证明你的观点，你就是口水再多，理论再严谨，对我根本就是对牛弹琴！




屁股是什么？屁股就是讨论问题之前约定的前提条件，就是你证明一个定理使用的公理！如果你连公理都没有，你还证明个什么？

ajoo说公理就是“过直线外一点，有且仅有一条直线于已知直线平行”，JavaEye众人说说公理就是“过直线外一点，有多条直线于已知直线平行”，好了，讨论吧，于是讨论了200多贴，结果就是自说自话。



我也在abp注册了，去年就注册了，我在abp注册并不能够改变我的项目实证主义的思维逻辑方式。这里不是在党同伐异，而是在区分两种不同的逻辑思维方式。如果你习惯了用项目实证主义思维习惯的话，你在abp难免就是一个异类；同理，如果你习惯了严密数学逻辑推理思维习惯的话，你在JavaEye就会格格不入。

更广泛的意义上来说，这是做Java的人和做cpp的人的典型思维差异。一个更加关心项目实施，一个更加关心语言细节。

昨天我还和Quake聊天。我举一个例子：

要写一个MD5加密算法来加密用户密码，Javaer怎么做呢？

Javaer打开Google或者SF，搜索出来一堆MD5实现的代码，然后比较了一下，挑了一个比较满意的代码import进来，开工了。

cpper嗨悠嗨悠的自己的MD5算法写出来了，写完以后，打开Google，搜索出来一堆MD5实现的代码，然后比较了一下，不行，为什么我的算法实现竟然比Google出来的算法慢了1秒，我改我改我改改改。终于，我的算法效率击败了任何其他算法实现，我露出了满意的笑容。



不是为了给自己找台阶，是为了让你明白思维基础不同的话，讨论的话题对一方来说有意义，对另一方就毫无价值。

拿上面的例子来说，我是Javaer，你别跟我谈什么MD5算法实现，对我毫无意义，但是对cpper来说，就是非常有意义的事情了，算法的执行效率和内存消耗对他是非常敏感的东西。

你要明白思维基础都不一样的话，根本就没有讨论的意义。你再和我讨论你的MD5算法多么多么伟大，我也只能打哈欠。你非要按着我的脑袋，要我承认你研究MD5算法是有意义的事情，我也只能敷衍了事，除非你给我证明，由于采用了你的MD5，而不是我Google出来的MD5让我的这个软件整体开发效率提高了n个人月，那我会承认你的算法有价值。可是你现在竭力要证明给我看的是你的MD5节省了几个字节的内存，提高了几秒的速度，我能不感到厌烦吗？最后你还按着我的脑袋和我讨论到底是你的算法好，还是google出来的算法好，我最后只有精神崩溃。

把我的回复也转过来：

java vs. cpp

javaer vs. cpper?

这里的描述与对比，颇有些漫画的感觉。我不认为是对实际情况的确切的总结。

至于说到两个板块的划分，我理解你的意思了。也就是说：“企业与非企业，实际与非实际”的讨论。不是简单的高低之分，而是是不是面向实用的划分，我的理解正确吗？

// new
Color w = new Color();;
w.r = 255; w.g=255; w.b=255;
w = new Color(255,255,255);;

// 静态工厂
w = Color.Instance;
w.r = 255; w.g=255; w.b=255;
w = w.FromRGB(255,255,255);;
w = Color.White;

w = new Color()和w = Color.Instance是等价的
w = new Color(255,255,255)和w = Color.FromRGB(255,255,255)是等价的

客户最喜欢的应该是w = Color.White,当然前提是客户正好需要白色

只有在w = Color.White的情况下才能体现出静态工厂的优势，也就是定制的价值