Java 专业人士必备的书籍和网站列表

摘要：

书籍

每个程序员都会有一些由于经常被当作专业资料参阅而磨坏的书。下列书籍应该是 Java 语言程序员的书架上必备的。书很贵，所以我有意将这份列表弄得很短，仅限于重要书籍。

Thinking in Java (Bruce Eckel)

Thinking in Java, 3rd edition （Bruce Eckel; Prentice Hall PTR，2002 年）
Java 编程思想：第3版 （陈昊鹏 等译; 机械工业出版社，2005 年）
Eckel 的书对于学习如何在 Java 语言环境中使用好面向对象技术极其实用。书中大量的代码样例解释了他所介绍的概念。文字出自一个并不认为 Java 技术总是正确答案的人，所以相当地实用。Eckel 具有多种语言的大量经验，还有用面向对象方式进行思考的扎实技能。本书将这些技能放到实用的 Java 语言环境中。他还在写一本新书，名为 Thinking in Enterprise Java。

Effective Java (Joshua Bloch)

Effective Java: Programming Language Guide （Joshua Bloch; Addison-Wesley，2001 年）
Effective Java 中文版 （潘爱民 译; 机械工业出版社，2003 年）
本书是理解优秀 Java 程序设计原则的最佳书籍。大多数材料从其他的 “学习 Java ” 的书中根本找不到。例如，Bloch 书中关于覆盖 equals() 这一章是我读过的最好的参考资料之一。他也在书中包括了很实用的建议：用接口替代抽象类和灵活使用异常。Bloch 是 Sun 公司 Java 平台库的架构师，所以他透彻地了解这门语言。事实上，他编写了该语言中大量有用的库。本书必读！

。。。。。。

。。。。。。

。。。。。。

这个话怎么说的这么不顺啊，换种说法。芒果软件，是一群技术精英的名字，我们来自四面八方，为了一个共同的前途走到一起，开始了一款软件从创意、设计到开发、测试、上市、销售，以及未来将成为国产软件之骄傲的传奇之旅。。。。。。

我们所说的这段软件，就是XMIND！它是第一款可视化思维工具，也是目前市场上唯一的同类产品。登陆我们的网站可以看到它的介绍和截图：
http://www.mango-software.com/
以及免费下载beta版：
http://www.xmind.cn/

[什么是可视化思维工具？]
很多管理咨询公司和培训公司，以及很多中学和大学的教师，他们在传授一类方法，或开设一门课程，题目可能是“如何提高你的工作效率”。 这类课程80％的内容是很无聊的，学员也不太喜欢，但是有20％的内容是激动人心的。我们发现这激动人心的提高工作效率的方法就是用形象的思维工具帮助思 维。比如很多管理咨询公司和培训公司会开设名为“思维导图”的课程，课上要求学员们用纸和笔把自己脑海中随时冒出来的创意随时记录下来。

记录的方法是在纸的中央画一个椭圆，里面写上中心主题，从这里发散出去想，想到的内容标为分支主题，每个分支主题还可以再发散，字写在线上，线划到 哪儿都要多划一点，这样就促进了自己的思维，这种思维方式比写文章要快很多倍（如果你没试过是无法想象的快），很快你就写满了整张A3纸！

即为别人培训又会做软件的我们就想到用软件来实现这一切！因为软件绘制思维导图，可以大大提高绘图制品的价值，不仅可以自己看，还可以与别人分享， 最重要的是即使修改。如果在纸上绘制的时候把一个分支错误的连接在了另一个分支的后面，就无法修改了，如果是重要的图，就必须重新绘制，但是软件就不怕 了。另外，软件还可以排版，或者将某个思维导图导出成Word/Powerpoint的格式，再进一步利用，这就延长了办公软件的流程，从用户脑子里想的到纸上打印的完全的连接了起来。

作为补齐最后一公里的软件产品，可视化思维工具还是跟其它Office软件有很大的不同，首先，Word和Powerpoint几乎都是以线性的方式组织文字和内容的，这和人脑的结构有很大的不同，因为人类都是以发散的方式思 考问题的；其次，Word和Powerpoint在调整篇章结构上太繁琐也不直观，很多用户都反映，他们在写文章或制作幻灯片之前都先用XMIND列提 纲，以便于谋篇布局，然后再为每个分支填入内容，之后还可以持续优化篇章结构，完全确定了以后，再用XMIND导出成最终需要的格式，修改错别字和最后排 版。

除了绘制思维导图以外，XMIND还包含了很多其它符合人类基本思维方式的图形，我们将这类图形统称为“思维图”。XMIND提供了在线更新的功能，XMIND的用户还可以从芒果软件的网站上源源不断的下载更多的思维图的种类。当然，我们只作最重要的，适合大多数人的，具有个性化的图形还是要靠用户自己用XMIND丰富的个性定制功能自己设计，并提取模版，相互交流。

可视化思维工具的另一大类用途是与他人交流思想。我们有很多客户是大企业的销售经理，他们在向客户演示自己产品和服务的过程中引入了XMIND，并获得了很好的反馈效果。因为它的形状是最适合人脑思维的，所以能表达的信息也最多最精确，也最容易被别人接受。XMIND的图标库也为用户绘制的思维图提供了额外的亮点，图形+图标所具有的表达能力是非凡的。此外，咨询公司和培训公司还辅导学员们利用XMIND帮助记忆和会议记录。最后，XMIND可以将同一个主题的所有思维图整合在一个文件里，因为用户愿意将“晨会计划”、“晨会内容”、“参会人员”和“会议反馈”等主题放在一个文件里，便于发给自己的boss。

上面这些就是可视化思维工具的主要功能，了解一下XMIND 2007就会发现它的功能还远远不只这些。芒果软件的宗旨就是为广大用户提供最适合思维的软件，而XMIND的宗旨就是整理您的思维、发掘您的潜意识、激 活您的创意灵感，最后，帮助您绘制漂亮的图形。让Google去搜索网络吧，我们搜索的是您的大脑！

[谁将会是XMIND的用户？]
XMIND有两类大的用户群：

1。高层经理、白领精英、办公室一族、政府公务员
特征：每日工作用脑量很大，处在现代办公环境中，常常需要计划、决策、记录、创意、演示、与人交流等等，工作节奏很快，工作时间中使用电脑占一定比重。

2。中学生、大学生、中学教师、大学教授
特征：每日学习、工作用脑量很大，常常需要记录、总结、归纳、综合、交流等等，工作、学习繁忙，使用电脑占一定比重。

芒果软件实验室正在研发中的项目Brainy（利用盛行于欧美，风靡于全球的思维导图理论）将会成为未来人类离之不得的全脑思维伴侣，它利用计算机软件技术和全脑思维艺术将人们的大脑和思维带入一个积极、高效的全新领域，Brainy将会在人们日常办公和生活中帮助用户增强记忆、规划写作、促进团队合作和内部沟通，在客户演示、会议记录、个人计划、项目管理、青少年教育等方面更是发挥着不可估量的作用。

Brainy不能取代任何Office 办公软件，却能和当前的Office紧密集成，成为办公软件生态环境中的一员，Brainy存在的目的是为了填补用户的大脑和办公软件制品之间的鸿沟。多数用户可以在五分钟之内上手，并在第一次试用之后就离之不得。尤其对于英文区国家的从小在这种氛围中长大的用户而言更是容易接受这种理念。也正因为如此，芒果软件实验室从成立之初就把国际市场当作最重要的市场来看待。

目前Brainy仍在开发阶段，芒果软件实验室需要有理想有抱负有能力有信心的“四有”技术骨干和创业精英的加盟。我们以Eclipse RCP为产品的运行平台，以测试驱动为产品的开发过程，以大量开放标准和开源软件为降低产品成本的有效手段，以全球第一的思维导图软件为产品的战略目标。

芒果软件实验室在技术上重视重构和复用，在经营上重视产品化和全球化，在管理上重视“团队综合能力”和敏捷开发，实验室还会定期聘请“武林高手”现身讲座，让每位员工每周都有培训的机会，每月都有培训别人的任务，定期参加Code Review，量身订做技术课程。

思想为箭，芒果做弓。一群充满激情和个性的年轻人正试图通过他们的努力去改变人们的思维方式，乃至改变整个世界。

加入我们，你一定会大开眼界！

公司主页：  http://www.mango-software.com

有意者请联系（邮件请包含个人简历）：hr.mangosoft@gmail.com

briansun> (To Admin) admin:我刚刚掉线的时候还剩3分钟，能否将着3分钟补回来
briansun> (To Admin) admin: 我已经完成了代码，但是在点Compile的时候掉线了
visualage> (From Admin) briansun: 报歉，不能。
briansun> (To Admin) admin: 我掉线的时候，系统自动log off，然后计时仍然在继续吗？
visualage> (From Admin) briansun: 是的。
briansun> (To Admin) admin: 那不是很不合理？
visualage> (From Admin) briansun: 我们认为这样才合理。
briansun> (To Admin) admin: 我后来又连续登陆了4～5次都没有成功才耽误了时间
visualage> (From Admin) briansun: 不然你不是可以登上来，看了题，下去做，做好再发上来？
briansun> (To Admin) admin: 你们为了杜绝这种情况就把一些水平高但是网络环境不好的人拒之门外？！
visualage> (From Admin) briansun: 首先，断线而导致来不及的人，比offline下去作弊再上来帖的人，肯定要少得多。
visualage> (From Admin) briansun: 其次，真正水平高的人，不会在快来不及的时候才交。
briansun> (To Admin) admin: 我能不能再做一次别的题目，用刚才那么多的时间？
visualage> (From Admin) briansun: 不可以。
visualage> (From Admin) briansun: 一个人只允许有一个账号。
briansun> (To Admin) admin: 难道公平和多少有关吗？？！！
briansun> (To Admin) admin: 真正水平高的人可以喝杯咖啡再来做题吧？
visualage> (From Admin) briansun: 真正的选手，相信不会在比赛进行当中浪费时间。
briansun> (To Admin) admin: 但是网络浪费了我的时间！
briansun> (To Admin) admin: 你们对网络质量不好的人一次机会都不给吗？
briansun> (To Admin) admin: 那我应该投诉Google还是TopCoder还是中国网通？
visualage> (From Admin) briansun: 投诉谁也没有用。
briansun> (To Admin) admin: 你是哪个公司的？员工号多少？我投诉你！

之后他再也没有回复。技术问题已经使我很恼火了，居然还有态度问题！我还是上篇那句话，我可以驳倒他，但是却不能对这场比赛有任何影响，只能眼睁睁看着它继续沿着“不公平”的道路走下去。后来我看了一下论坛，多数人反映教育网容易掉线，看来有志向的大学生们是跟Google无缘了。

抓狂的泡泡

但是，最令我气氛的是，国内软件除了100%PureJava的外，几乎清一色没有Mac版，但是据苹果公司的数据看，中国的苹果电脑用户并不少，这是为什么？！起初我站在软件生产厂商的立场上，觉得应该“把有限的资源投入到最广泛的市场上去”，但是随着时间的流逝我越来越感觉到这是欺负人（当然也是欺负自己），为什么呢？我有三个理由：

1。把应用从Windows上转移到Mac OSX上非常简单。Mac OSX的架构看起来复杂，其实很简单，就是BSD+Step，你用FreeBSD+OpenStep就可以模拟一个了，上面有GCC，还有支持老式MacOS的API，要知道，MacOS跟Windows的相似程度要大于其它任何视窗系统。

2。拱手把市场让给别人。Mac OSX上没有金山词霸，我只好用Google工具栏的及时翻译；Mac OSX上没有QQ，我只好用Sinomac的isQ（其实大部分时间我用iChat，这是一个Mac OSX自带的聊天工具，因为支持Jabber，所以可以跟Google Talk的用户聊天）；Mac OSX上没有Maxthon，我只好把机会留给Firefox；Mac OSX上没有FlashGet，我只好下个iGetter并且一直在用试用版；Mac OSX上没有紫光拼音，我。。。我。。。我什么办法都没的想，因为老外不会去做拼音输入法。

3。态度问题。抱着激励国产软件的想法，我分别给QIM（一个很好的输入法）的作者和紫光拼音的支持人员发了邮件。前者给我回了邮件，说他不懂双拼所以不做，然后我又回了邮件，告诉了他双拼的概念，任何一个有输入法常识的人都知道，双拼只要在全拼上稍稍修改就可以了，如果QIM真的全部代码都是他写的话（或者只要他理解全部代码的话），做出这样的修改不到8个小时的工作量，可是我收到的回复邮件还是说“不做”，理由居然是“...完全依赖于输入的上下文关系...”。天哪，我简直不敢相信自己的眼睛，我开始担心起自己是否有编程的天赋了，为此我特地请了一位同事——他是拼音加加的创始人之一——证明了这种说法是站不住脚的。但是我没有再给他任何回复，人家毕竟是一个人在无偿的写一个软件，即使我能在技术上驳倒他也不能“要求”他做任何事情。我突然想起来很久之前老外曾经议论过免费软件有没有服务的问题，可惜这种争议在国内毫无动静，我的同事还笑我说“国产软件连收费的都没有服务，更不要说免费的了”。真的吗？我的心巴凉巴凉的。紫光华宇更是直接了当的说不做。

稍有一些编程常识的人都知道，从Windows移植到Mac OSX是很简单的，稍有一些输入法常识的人都知道，从全拼到双拼的改动是很小的，可是国内同行，你们在面对上面两个常识的时候，在想什么呢？？

抓狂的泡泡

事实上这个世界上所有绝对创新的产品——注意，是绝对创新——都是超前的，不易被人理解的，流行不流行都是它的表面现象，它的本质是颠覆了人们之前 的某种理念。历史证明这种创新很难成功，想要举出一个伟大的发明因不合时代要求而饱受磨难的例子非常容易，找个小学生就可以了；历史证明这种创新很难成 功，但iPod不是失败者中的一员；历史证明这种创新很难成功，除非。。。。。。

除非什么？先看看我常说到的三个例子。

iPod是人类历史上的一个歹怪的东西，它违反了人们之前对MP3播放器的要求，它既不轻也不小，没有击中人们对随身听的主流需求；但是iPod引 入了另一些优点。。。可以播放很久。。。你都不知道自己想听什么。。。华丽的外观。。。等等等等；事实是iPod取得了市场的胜利，传统MP3厂商推出了 大量模仿iPod的产品也丝毫未能撼动它的地位，iPod嘲笑别人“你们不了解客户的真正需求”，抨击iPod的人则说“iPod将用户导向了一个错误的 领域，用户是缺乏理性的，他们并不了解自己的需要”，这就像辩论赛的双方，正方说反方没有读懂辩题，反方则说正方在歪曲辩题。

另一个例子来自Google Talk，现在我已经基本离不开它了，虽然在几个月前我曾扬言“聊天工具我只要QQ”。Talk的出现来自对传统及时通讯工具（IM，Instant Message）和“因特网实时聊天”工具（IRC，Internet Realtime Chat）的反叛，这些工具经过近10年的发展已经越来越趋向复杂和娱乐化，互联网上随处可见“QQ大战MSN”之类的帖子，评价它们娱乐功能之间的差 异，但是Talk却以简洁的外观和几乎可以称为“功能不全”的软件设计杀入市场。与前一个例子相比，Talk并未取得什么可以称道的成功，但它的成功是必 然的，我有我的理由。

问题出在哪里？为什么会有些违反市场原理的所谓绝对的或彻底的创新取得胜利了呢？问题场出在我们的意识上。这就好比你遇到一位美女，你把她跟老婆做 了一个简单的比较后发现她比老婆更性感，但没有老婆可爱贤惠，这时美女向你表达了爱慕之心，怎么办？哈哈。我用脚趾头想一下也知道会有两种结果发生，一种 是在犹豫痛苦了很久之后终于还是回到老婆的怀抱，让美女失望即使她取得过短暂的成功，另一种可能是和老婆之间产生了越来越多的隔阂（不知道这些隔阂是从哪 来的）最后“不得不”分手，然后在痛苦了一小段时间之后又找到了新的归宿。而我要表达的观点是，这两种结果产生于两个不同的隐喻。在前一种情况里，美女向 你示意的结果是你认为她可以成为你的老婆，也就是说，她的目的是老婆，她的竞争对手是老婆，你必须在她和老婆之间作出选择。而在后一种情况里，她为自己设 定的隐喻是“情人”，她的目的是成为你生活中的另一个角色，因此你很快就接近了她并在不经意间帮助她取得了最后的胜利。

这个例子足够夸张了吧？再看看前面两个例子，开头那篇文章引起了我的注意，因为作者的观点是iPod的隐喻并不是一个MP3随身听，而是一个晶体管 收音机的替代品。（做惊讶状）试想人们为什么听收音机，是为了随时随地可以听到已经录制好了的节目，这些节目包括多数具有听觉享受的声音内容，并可以随意 切换，而现代收音机的缺点是这些节目不能随意组织，有时还会被地理位置影响收听品质。iPod没有地理位置的影响，节目可以随意组织，（也可以 Shuffle），更重要的是，现在的互联网和BT下载等技术已经可以很方便的找到所以你喜欢的节目，除非你喜欢某个电台的DJ，或者喜欢打热线电话参加 互动游戏，否则iPod都可以胜任。此外，我们应该对网上可以下载的声音内容越来越丰富充满信心，我之前的一个室友一直以听mp3的评书为杀时间的主要方 式。

我已经离不开Talk了，自从我跟一个武大的MM常用Talk聊天之后，现在跟老婆也总是用Talk聊天，Talk的好处是轻磅，速度快，窗口小， 不占空间（桌面空间和内存空间），没有乱七八糟的提示和广告。与Gmail良好集成，最近还发现它的一个好处是使用开放协议，所以在我刚买的iBook上 没有Talk我还可以用Google帐号跟Talk用户聊天（用iChat），这样又充分利用了iChat的优点。上次见到dudu（很久了）的时候还谈 起Talk，很多人认为Talk的优点在于跟Gmail的良好集成，这意味着Talk存在一个很有竞争力的隐喻：“能聊天的邮件提醒器”。如果你大部分的 网络生活都跟Gmail联系在一起，那你真的会离不开它。

隐喻的魅力是可以让一个不易被人理解的创意变得易于被人接受，不理解不要紧，感情上的接受是最重要的。事实上，隐喻并不是对事物表面现象的某个概括 或总结，而是对事物本质的歪曲的描述。虽然歪曲，但毕竟是体现本质的。不仅不同的隐喻可以导致不同的后果，同一个隐喻也可以导致不同的后果。最初老师在课 上讲“菜单”，很多学生都笑，“此菜单非彼菜单也”。Windows中提到的主菜单有很多，每个窗口都有一个，优点是菜单的内容与窗体（甚至窗体的内容） 相关，在同一个桌面上可以看到主菜单的比较，缺点是带来了大量的视线转移，且存在菜单被遮蔽的可能性。Mac系统上的主菜单是全局唯一的，随当前激活的窗 体的改变而改变，优点是为不会出现用户“找菜单”的局面，缺点了降低了菜单在应用程序功能中的地位，好在多数用户在从“初级”向“中级”的转变中，对菜单 的依赖越来越少，对快捷键（Mac上称“键盘迅捷”）的依赖越来越多。

泡泡很久不见

第二件事还是做广告。在上课的空余时间里，我看了<<UML Distilled>>这本书，最新的版本是第三版，里面涵盖了UML 2.0的主要内容，Martin Fowler的书我全买了，也全看了，每一本都是经典，没有一句废话。可是令我有些不爽的是这本书的翻译。这本书的翻译者和本书第二版的翻译者是同一个人，可能这位翻译者在翻译上一个版本的时候UML界的一些术语的译法还没有统一，所以用的词和我们后来看到的多数关于UML的主流文档和书籍中不太一样，为个人阅读带来了一些不便，这一版他还沿用了上一版的译法，可能是译者很满意于自己以前的作品的缘故吧。（本条广告也不收Martin Fowler的钱了）

最后一件事是想讨论一下这本书里的一个译法：译者把所有的Use Case都翻译成了“用案”，而不是我们闭着眼睛也能说出来的“用例”。事实上China-pub上曾经还有翻译成“用况”的，并且讨论也十分激烈。关于这个词的翻译我想了很多，（没有利用上课的时间想，呵呵），最后我还是觉得可能“用案”更贴切一些。我的理由是这样的：case一词在国内用的最多的地方一般都翻译为“案例”，主要出现领域是管理咨询业和大学教育，所以为了保持其字面意思，还是翻译成“用例”或“用案”比较好，至于“用况”，不容易让人联想起Case来，要知道技术翻译最重要的一点就是“隐喻”，任何翻译都应该保证“Use Case”和“Test Case”在本质上是一种东西，二者的差别应该体现在用途和形式上。就像男人和女人的本质都是人一样。如果Test Case能翻译成“测况”的话，那我就实在佩服这位译者的想象力和勇气了，因为“测况”很容易让人联想起“测试实况”。接下来比较“案”和“例”，因为案有书面表示的意味，与公文打叫道的工作常常被称为“文案”；而“例”既有依据的意思，又有规定的含义。我认为使用“用例”一词的译者认为用例既是一种依据也是一种规定，所以应该用“例”。但事实上使用Use Case一词的老外也许并不是这种看法，他们可能既不是想要依据，也不是想要规定（Specification），而仅仅是想要一种结构化的文档，该文档以定义角色和封装角色的目标为表现手法，很好的为需求的描述和特征的枚举提供了。所以，“案”更能表示其英文原意。而Test Case则可以翻译成“测案”，如果不舒服，就叫“测试案例”好了。下面附上<<国际标准汉语大词典>>对这两个字的分别解释。

案
1.长形的桌子或架起来代替桌子用的长木板：～子。～板。书～。条～。拍～而起。
2.提出计划、方法和建议的文件或记录：档～。备～。议～。提～。方～。有～可查。～卷。～牍。
3.事件，特指涉及法律问题的事件：惨～。血～。～件。～例。～犯。破～。
4.古代有短脚盛食物的木托盘：举～齐眉（形容夫妻相敬）。

例
1.可以做依据的事物：～证。～题。举～。～句。～如。
2.规定：～外（不按规定的，和一般情况不同的）。体～。凡～。条～。破～。发凡起～。
3.按规定的，照成规进行的：～会。～假。～行公事。
4.调查或统计时指合于某种条件的具有代表性的事情：事～。病～。案～。

我本人英语水平很烂（不是谦虚），所以对于翻译也没什么发言权，更不想跟技术翻译精英们叫板，这篇随笔仅是随便聊聊，弥补一下中秋之夜没有写blog的憾事罢了。

2。语言级猜想。
AOP的真正实现是在一个特定的语言基础上的。比如数年之后，人类开始普遍使用K语言（K是J的后一个字母），K语言在语言本身上就可以编织和横切。此时AOP才得到真正的成熟，因为程序员在编写代码时可能根本不知道自己用到的是曾经的OO还是现在的AO，只有了解K语言虚拟机构造和背后实现的人才知道。但是，可能由于人固有的思维方式的问题吧，AOP仍然不会比OOP要使用的更多，甚至有可能仍然是Kiczales所提到的15% Solution！但是，从语言的角度去实现AOP也许会给人类的编程观念带来巨大的变化，这种变化就像OO所带来的一样。

3。存在AOD/AOA猜想。
OOP对人类的影响远不如它的两个弟弟OOA/OOD，后两者已经为整个软件开发行业带来了一次意义深远的革命，它至少使得全世界开发团队的人数扩大了10倍，开发工具和平台的复杂程度增加了10倍，完成客户某些简单要求的成本降低了90%，唯一的遗憾的是，软件开发的效率几乎没有数量级上的变化（依据《没有银弹》）。既然存在AOP，我们猜想也会存在AOD/AOA，比如会存在面向方面的重构手段，面向方面的设计模式，面向方面的最佳实践，面向方面的过程管理，以及在UML的未来版本中看到为面向方向而专门做的改进，甚至添加一个新的UML图类型。当这些东西都产生的时候，AOP才真正发展到了鼎盛时期。

4。可执行用例猜想。
AOP是一个广泛适用的充满想象空间的新技术，但是目前人们对AOP的研究方向过于狭窄，大部分声称正在研究AOP的开源项目其实是把AOP当成一个辅助工具来使用，这些项目中又有相当一部分是在做企业开发环境下的容器，他们并没有针对AOP本身进行开发。事实上，依照Jacbson的说法，AOP将直接导致软件的开发分为两种形式——对模块的开发和对用例的开发，现在的用例仅仅是图纸，必须要转变为OO代码才能执行，但是一旦有了AOP，AOP可以直接依据用例的定义，将多个不同的模块（可能来自不同的开发单位）连接起来，形成方面，而方面本身是可以执行的（语言级猜想），所以用例也就不再是图纸而是可以执行的了。这对于以UML为核心的现代软件过程来说，是个极好的信号。

5。标准化猜想。
OO的成功经验告诉我们，要想取得最后的胜利，就要一致对外，统一了内部的概念，剩下的争论就只有实现问题了。我个人认为，多数OOP语言在概念上都是一致的，这种概念被语言学称之为语义，多数OOP的语义来自Smalltalk和C++这些早期尝试者，少数来自Java这种在技术的成熟期涌现出的商业产品。AOP目前还面临着这个问题。业界对AOP的标准化过程有两个猜想，一是由AspectJ领头，各大AOP实现都以AspectJ的语义作为研究问题的基本用语，设计和实现沿用现在的思路；另一个猜想是由权威组织，（开源、商业、或全球研究组织），如Eclipse/IBM/OOPSLA等等拿出一个统一的AOP语义内核，所有AOP项目都以该内核为基础开发。Java虚拟机是前一种思路的成功案例，后者则以XML为代表。

6。全静态编织猜想。
下面讨论一个实际的技术问题。时下多数AOP项目采用的编织技术无外乎两种：静态编织和动态编织。前者是指在编译前（预编译期）、编译期、和编译后编织，后者是指在运行期编织。Kiczales认为虽然没有明显的技术缺陷，但动态编织可能会面临一些发展远景的问题，他称之为“软件的演化问题”。不知道我对大师观点的理解是不是准确，我认为由于被编织的代码是在变化（发展）中的，我们总是希望这种变化对编织本身的影响最小，这时静态编织面临的问题最多就是重新编译，而动态编织可能不会那么简单。此外，全静态编织会导致另一个优点——这听起来有点奇怪——就是能力较弱，因为全静态编织继承了OO语言本身的约束，比如Java的约束和.NET之CLR的约束等等，这对于更规范的使用开发利器是大有好处的。“应该对人类准备大规模应用的每一种新工具小心钳制。”

7。AOP的诞生之迷猜想。
Kiczales先生在从事AOP的研究和开发之前也曾接触过其它对OOP的改良研究，其中包括反射和元对象技术。事实上，心平气和的说，后两者的变通能力和灵活程度都在前者之上，但是正因为如此，语言学家们认为，这些技术并不能有效的改善OOP的弊端，甚至还有可能引狼入室，带来新的“狼人问题”。后来，当Kiczales发现AOP时，他明白这才是人们真正需要的，他认为他们抓住了问题的咽喉。时至今日，AOP的实现技术已经千姿百态，百家争鸣了，但是，AOP创立之初的种种想法也在这种百花争艳中渐渐被人们遗忘，现在利用反射、元对象技术以及种种双刃剑式的技术来实现AOP的想法已经像争抢参院席位一样争夺市场的认可，这是事物的发展还是理想的倒退？AOP何时才能回归它的本原？上天为它安排的命运究竟如何，我们拭目以待。

最近，我和我的几个朋友正在组织一批开源斗士们合作编写AOP.NET，这是一个开源软件，在博客园上可以看到部分有关该项目的消息。但是由于种种原因，我们对一些基本的问题还没有达成共识，本文来自我对AOP的一贯看法，也是我对社团里很多问题的一个集中性回答吧。

开源泡泡
（转载本文需注明出处：Brian Sun @ 爬树的泡泡[http://www.blogjava.net/briansun]）

最近十年管理学界对体验经济的理论层出不穷，形成理论界的一大热点。总的来说，体验经济是将未来的经济模式，同产品经济、商品经济和服务经济相区别，对这个概念不了解的朋友可以先看一个写在《体验经济》一书扉页上的这个案例：

Rebecca的妈妈小时候过生日，Rebecca的奶奶自己亲手做蛋糕为她庆祝，她的原料比如奶油、鸡蛋、面粉等等都是从邻街的小店里面一美分一美分买来的。Rebecca小时候过生日，妈妈打电话给附近的一家蛋糕店，蛋糕店立即送来的美味可口的蛋糕，这样Rebecca可以请邻居家的小孩来过Party，这个蛋糕只要花十几美元。现在Rebecca的女儿过生日，Rebecca将整个生日交给Disney公司去办，公司的姐姐们带Rebecca的女儿和她的小伙伴们去城郊的一个小山坡野营。在那里，孩子们学会了自己搭帐篷，挤牛奶，采野生的葡萄酿酒，整理破旧的茅草屋。在一天的猎奇旅程之后，公司送每一位孩子回家，Rebecca付给了他们一张$146的支票。

尽管体验经济首先是在餐饮、旅游、娱乐、零售等行业首先发展并扩散开来，但是我相信，它迟早会在软件领域展露头角。我的这种想法由来已久，在最近一段时间里这个想法被激发，导致我写这篇文章，我认为体验经济至少应该在下面四个方面对软件界有所帮助：

1）近似帮助的导航。
如果你还没有下载Eclipse 3.1，那么你还不能真真了解我的意思。看看Eclipse的Million Downloads Challenge吧，3.1版正式版推出的第一天全球下载量就接近20万份，这绝不是宣传的效果，而是全世界的软件开发人员和关注软件界成长的人们共同的精神支柱。3.1版在易用性上又有大幅度的提高，随处可见的Html风格的说明信息，从一个对话框到另一个对话框的“超链接”，首选项的搜索与过滤，首选项的编辑导航（前进、后退等），FastView可以变成内嵌Frame，任意输入框里的工具条，任意输入框里的感叹号、问号和小红叉，等等等等，无一不在3.0版已经很“花里胡梢”的界面上再“锦上添花”。并且，知道内情的人都知道，这些对用户眼球产生极大刺激的小技量，对于Eclipse来说是多么的轻而易举。这么说吧，这些东西放在你的应用程序里面叫做“特性”，放在Eclipse里面叫做“对特性的应用”。

2）软件为什么不能用画的。
既然标准控件可以拖到窗体里变成代码，为什么用户不能用笔画一些代码出来呢？我想未来的软件应该会以某种“更自由”的方式向用户提供体验。比如，用户可以画一个圆作为输入框；用户可以画一条线来表示状态条；用户可以画一个图标或写一个单词，再和一个程序定义好的Action建立链接；用户可以画一个小人提供导航；用户可以规定什么样的状态用什么样的符号表示；用户还可以规定在哪里可以显示固定的及时帮助，什么时候可以显示浮动的及时帮助；最后，用户被要求画一个区域（可能是不规则的多边形）来把刚才画的那些东西装进入，这个区域就是我们所说的窗体（想想很多播放器都支持不规则的图形作为skin）。

3）同时面对新手和熟练工人。
关于气泡式的及时帮助，业界有很多的争议，这些争议大都来自不同领域的不同需求。比如一个面向客户的财务系统，开发者可能希望随时随地都能让使用者知道下一步该怎么办（或者这一步该怎么办），可是一个面向企业内部的财务系统，投资商则更愿意花费少许培训费用来使该系统的使用者更加熟练，这些费用可能会比在软件中加入大量的帮助更为经济，更重要的是，去除这些气泡往往会提高使用者的效率，给企业带来更多的好处。所以体验经济要求我们的软件理念能在两种模式之间自由切换，甚至可能会同时体现在同一个系统上，比如某个在线游戏，新手希望能随时随地得到提示，而老玩家则希望在某个选项页上关掉这些提示——以速度取胜。

4）功能微调和界面微调。
多数软件已经开始向Extendable转变了，少数精英已经开始向Pluginable（这是我自己造的词，被画上红线别怪我，呵呵）转变了。有图形处理和媒体制作软件，如Photoshop、Fireworks、Flash，有开发工具IDE，如Eclipse、SharpDevelop，有浏览器如Firefox，有小工具如我正在使用的EmEditor等等，在SourceForge的排行榜第一名上待了很久不愿下来的Azureus - Java BitTorrent Client也是Pluginable的。更有令人惊奇的，有一个叫Java Plugin Framework(JPF)的项目可以为所有Java软件增加Pluginable的能力，这个项目吸收了Eclipse的思想，但是比Eclipse的插件平台更通用，更具扩展性，也更严格。至于界面上的微调，Eclipse也为我们作出了榜样，它可以允许成千上万个View和Editor并存在同一个窗体里，并提供了最大化、最小化、FastView、内部Frame等多种展现形式，（意思是说它们不会太挤），甚至可以在界面上搜索和过滤这些parts，这样做的主要目的是将用户工作中能遇到的交互事件划分成更细小的颗粒。我认为未来的软件能让用户在更小的颗粒度上调整UI，比如某个用户会在用软件时自言自语：“这个的Label我不喜欢，我要变成Icon；那里有个Table太繁琐了，换个饼图看看；哦，对了，这里有个讨厌的文字框，小样儿，我早就看你不爽了，干掉，直接写进log吧！”

在本文的最后我还要告诉大家的是，虽然很多软件用XP结尾来标称自己是“用户体验版”，比如Windows xp和Office xp，但是我仍然认为体验经济的时代要求未能很好的表现在当前的主流应用中，无论是操作系统、办公软件、在线应用，或者ERP，但是我们已经可以在一些游戏、及时消息软件或大师作品中看到一点希望。重复本文开头时的论点，我相信体验经济在软件的时代即将到来，如果您手上正在做的软件没有考虑这一点，那么还是请考虑一下吧，我们都不希望在这次浪潮中国产软件再次落后，如果要我给出一个理由来支撑我的观点，那我只想说——这是经济学的规律。

（转载本文需注明出处：Brian Sun @ 爬树的泡泡[http://www.blogjava.net/briansun]）

NXUnit is a NUnit -style unit testing framework about XML for .NET Framework. It is an extension to NUnit. It brings you the ability to do unit testing easily in XML applications. It helps you to concentrate on business logic of your XML application and improve your Test Driven Development(TDD) technics. You can directly compare one XML string or stream with another, er assert that they are equal, just like doing the same thing to two integers using xUnit. But without NXUnit, you must pay attention to whitespaces in XML strings, empty elements or attributes, unimportant order of elements or attributes, unneccessary comments and so on. It's similar with XmlUnit in some aspects.

Features

The current version is NXUnit 1.0rc1, July 2005. The following is the 8 features of this version, which you can find in the facade class XMLAssert:

    * Assert that two XML inputs are equal.
    * Compare two XML inputs and find all differences between them.
    * Assert that declarations of two XML inputs are equal.
    * Assert that document types of two XML inputs are equal.
    * Assert the validity of an XML input.
    * Assert that the evaluation of an XPath expression on an XML input will return the expected value.
    * Assert that an XPath expression exists for an XML input.
    * Assert that an XML input is included by another.

And you can change the properties of an instance of XMLAssert before an assertion or comparition, in order to:

    * Ignore the case of the elements' and attributes' names
    * Ignore XML comments
    * Ignore XML declarations and document types of both inputs
    * Ignore empty elements and attributes
    * Ignore orders of elements and attributes
    * Ignore unimportant whitespaces

Sample

 1    using System;
 2    using System.IO;
 3    using System.Xml;
 4    using NUnit.Framework;
 5    using NXUnit.Framework;
 6
 7
 8    [TestFixture]
 9    public class Sample
10    {
11        private XMLAssert xa;
12
13        [SetUp]
14        public void Init()
15        {
16            xa = XMLAssert.CreateInstance();
17        }
18
19        [Test]
20        public void TestMethod()
21        {
22