最近接二连三看到好几篇讥讽Firefox的文章，文章的作者大都是拿出现在几款流行的浏览器软件相互比较一番，然后得出“Firefox无论性能还是功能都不够好”的结论，然后再说Firefox社区的网民都TMD“不够冷静”，国内国外都像炒股票似的把这个原本“不怎么样”的产品抄的沸沸扬扬，如此如此，这般这般，我真的实在是受不了了，是到了我们这些人出来为Firefox正名的时候了！

首先，我们从Firefox的来出看，Firefox是由Mozilla基金会开发的轻磅浏览器，在此之前，Mozilla已经有很多浏览器了， Mozilla Suite，Netscape都是Mozilla开发的浏览器。那么在这种情况下Mozilla为什么还要做这样一个浏览器呢？我给出的答案包括两个部分：有效性和必然性。有效性参看我的另一篇Blog[]。必然性则是因为Mozilla 迫切需要一个平台来展示他的思想、理念，并告诫正在以网页为经营手段的人们标准化的重要性！请永远记住下面这个等式：

开源软件基金会 ＝ 软件界的传道者

他们做这些事情根本就是无利可图，只能依靠别人的捐助作为开发软件的成本。比如Firefox在刚刚上市放出beta的时候，为了扩大影响力， Mozilla决定登一则广告，于是四处筹集资金，最终从数千家赞助商那里筹集了25万美元的资金，并于2004年12月中旬在The New York Times上打了两个全版广告！你想想啊，数千家软件企业的期望，就为了这两个页面的广告如果说句不好听的话这两页纸会被多少人在上厕所的时候阅读然后索性用来擦屁股完全可以通过广告业的市调公司通过概率算出来！这是为了什么？我记得自己刚刚上网的时候就有人告诉我网络上什么人都有，但至少可以分为四种：商人、教父、狂热者和迷途青年。微软是彻彻底底的第一种人，Mozilla、Eclipse、Apache、JCP都是第二种，Maxthon是第三种，幸好这个世界还有传道者们的存在，否则我们都会变成第四种人，只会跟着商人和狂热者们走路。

是的，Mozilla正是要通过Firefox教诲我们他的圣经。有些人认为Firefox就是一个使用Gecko的Maxthon，我想说这些人大错特错，根本没有理解Firefox。引擎的不同是小事，遵从于标准才是正道。MSIE使用了大量的“专有技术”，使得别人针对MSIE开发的网站在标准化（一般指W3C标准）的浏览器上不能正常显示。也许有人会问，这个很重要吗？既然现在MSIE的用户数量如此庞大，那我们针对MSIE开发自己的网站又有什么错呢？答案是很重要！有错！我举个简单的例子，我们比较一下两个互为竞争对手的网站：IBM和Dell，他们都卖个人电脑，Dell的网站只能在 MSIE上正常显示，IBM的网站无论哪个浏览器都可以，这说明IBM遵循的是行业标准，而Dell使用的是微软特性。然后我们再看看他们两家公司的产品：IBM的电脑，捆绑什么操作系统的都有；而Dell的个人电脑，全部捆绑的是Microsoft Windows！还用我再解释吗？

有人认为Firefox占用太大内存了，我想问问他有没有用过Java，感受如何？Firefox占内存不是Firefox的问题，而恰恰在于操作系统 Windows的不合理性。Firefox的存在就有一个很重要的任务那就是跨平台，Firefox要用底层代码实现一个平台无关性体系结构，既是为了传道，更是为了那些从开源软件中收益的人们。有人认为Firefox结构太复杂，我想问问他有看过xpi文件的结构吗？xpi文件就是一个zip包！这一点又是Firefox从Java世界学来的，这还能叫复杂吗？比dll文件还复杂吗？Firefox还有比Java更绝的——允许插件使用COM！并且能在非Windows平台上虚拟出一个COM服务，这使得为Firefox编写插件变得更为简单，和可移植。如果Google为MSIE写了一个插件，那么他把这个插件移植到Firefox上的工作量只占10％。

有人认为Firefox功能太少，天哪，你不知道自己下插件啊！Firefox从一开始就没有把Maxthon作为自己的竞争对手，你知道是为什么吗？因为Maxthon在增强用户体验方面确实做的很好，而“Maxthon不足的地方不是Maxthon本身的问题，仅仅来源与它使用的是IE内核，所以 Maxthon会有很多安全性和稳定性方面的问题”。Firefox的对手是MSIE，为了更好的和对手较量，Firefox把增强用户体验的工作也交给了第三方插件开发商，毕竟Mozilla没有多少人手啊。Firefox所实现的都是不得不实现的，这恰是现代成熟的软件开发方法论所要教诲我们的。你看看：多页签是能力问题，换皮肤是架构问题，搜索条是易用性问题，DOM是规范化问题，JavaScript和XUL描述界面是平台无关性问题，XPCOM 是平滑迁移问题，而RSS则又是另外一个标准问题！哪一项是还可以从Firefox中剥离出去的？

至于插件吗，Firefox的主管说的很好，他说Firefox面世后只用了两个月的时间就获得了Maxthon花两年时间都没有的插件数量，这还不能说明问题吗？最近拜读了一位ACM老牛人写的关于插件服务的文章，其中提到良好的插件服务有两类，一类适用于单用户环境下大幅度提升可伸缩性，这种架构的完美实现就是Eclipse，另一类适用于多用户环境下大幅度提升安全性、稳定性和一致性，这种架构的完美实现就是Firefox。Firefox率先使用 RDF来描述插件，使用jar文件来打包资源描述，使用“中间定义语言”IDL来描述公共的COM接口，这些都是其它软件体系结构所没有的，也是大量软件架构师敢想而不敢做的！

最后一个问题就是Firefox不仅仅是个浏览器，还是一个RIA，就像Eclipse不仅是个IDE，还是个Platform一样。可以参考我的另一篇 Blog[]（我今天怎么老是做广告啊），以后我还打算写更多关于RIA的文章。

在批驳了这些人的文章之后，让我们再来看看Firefox究竟是个怎样的产品。下面我仅仅列出我所看到的Firefox的优点，至于这些优点是否会让您迁移到Firefox平台，我并不奢求，这是您的价值取舍问题。

1。标准化。

2。简洁化，最小内核化。

3。平台无关性。

4。安全型RIA。

5。多用户环境下的插件管理。

。。。。年轻人，开在我们有缘的份上，我决定卖这本<<如来神掌>>给你。。。什么？这本不合适啊？别急！还有很多本。。。。。。


说三道四的泡泡


下面介绍几种具有坏味道的代码结构，其中很多经验学习自Eclipse，与Martin Fowler不同的是，我找到的几种坏味道都存在于设计理念之中，而不是缺乏设计模式的抽象，也不是未重构的代码。先别急着反驳，也别急着嗤之以鼻，先想 想这些设计理念的优点，看看是不是微不足道，再看看这些理念的缺点，是不是有可能铸成大错，作者还给出了去掉这些坏味道的某个思路，即作者自己的思路，仅 供参考。最后，别忘了想想自己手中的软件的设计，看看会不会遇到其中的熟面孔啊。。。。。

1。味道：控件耦合。
“如果第一个复选框被选中，那么下面的文本域全部失效。”通过这种方式表述的效果在软件开发中经常遇到，很多人称之为“界面逻辑”，想想看，界面逻辑真的可以直接变成代码吗？
典型重构思路：有限状态机。
状态与控件属性集一一对应，控件属性被改变时，状态机收到事件，检查状态是否发生了迁移，如果是则向控件属性集的控制器发出状态迁移事件，控制器批量改变控件状态。

2。味道：控件/绘制器存在状态。
有人认为Motif和Windows已经差别很大了，有没有想过它们和IBM收银机上的字符界面差别有多大呢？既然差别这么大的绘制器仍然存在相同的复杂了（有时是很复杂的）状态，那我们为什么不把它们extract出来而要让它们冗余呢？
典型重构思路：视图的模型。
视图有视图的模型，并不是MVC中的模型，这种方式就是Swing的基础。

3。味道：视图发出有意义的事件。
什么？你的意思是视图应该发出无意义的事件咯？不是这样吗？视图应该不了解任何业务逻辑，也不应该了解任何界面逻辑，如果界面逻辑真的存在的话。
典型重构思路：事件翻译器。
视图发出无意义的事件，比如鼠标事件，键盘事件，或某个控件的事件，事件翻译器把低级事件翻译为高级事件，再把高级事件包装成请求，请求被传递给一个根控制器。

4。味道：动作/命令知道自己的形象。
很多时候，一个Action或者一个Command都知道自己叫什么名字，能不能被禁用，有没有被禁用，图标如何，甚至还知道及时帮助的字符串，执行需要什么条件，返回什么结果等等，如果这么做的话Action和Command就有了自己的视图状态，发出了第2种味道。
典型重构思路：动作代理。
重磅的工作交给代理完成，动作/命令只是一个视图的模型罢了。在UI系统装载之初，动作/命令被装载并绘制在界面上，直到用户点击或触发了这个动作/命令，它的代理才被调入并开始工作。

5。味道：模型知道自己的每一个用处。
有n种视图对应同一个模型，比如对一个网页制作工具来说，一个html文件至少有三种视图：代码、设计、预览。如果模型同时能满足这三种视图的需求的话，这个模型就太重磅了，而且还不好添加一种新视图。比如Dreamwaver的代码/设计页面。
典型重构思路1：一个模型，多个维度。
如果一个模型拥有n个维度，则n个对象，就可以确定一个事实，n-1个对象就可以得到一个线性聚集，n-2个对象就可以得到一个二维表。每个维度就是一组Interface,而事实的类型，其实是不可见的，（内部的巨大类型），只能通过维度确定事实，再提取事实的属性。
典型重构思路2：适配器模式。
模型首先实现最必要的接口，然后当需要模型实现某个非必要接口时，模型会主动或被动的适配为一个满足需求接口的“意外”对象。

6。味道：控制器变成顾问类。
有些人认为我们的社会需要复合型的人才，因为每个人都要具备管理的能力，控制器也要懂管理，它要负责视图和模型之间的交互。但是仔细想想，如果被模型以外的对象知道了业务逻辑的话，那模型还可以替换吗？
典型重构思路：控制器标准化。
控制器将请求包装为命令，并将命令交给命令堆栈执行。控制器并不了解模型，模型只能由模型自己了解，控制器也不知道领域逻辑，它只是做一些机械的翻译工作，并利用视图和模型提供的（互补相关）的素材，创建和模型相关的命令。

7。味道：模型变成无所不知博士。
在没有发生上面六种情况的时候，千万不要大意啊，你很有可能发生了这一种情况，恰恰是因为控制器和视图都不知道业务逻辑，模型才有可能发展为Dr.Know。但是视图往往是树状结构的啊，它怎么和Dr.Know合作呢？通过代理？还是Facade？
典型重构思路：复杂模型结构（树状、图状、知识/操作分离）。
如果有可能，模型也是树状的，可以和视图一一对应；如果这一点做不到，不要紧，可以把大模型划分成轻量小板块，或者迭代子，再用关系对象解释它们之间的关系；如果还不行，那总得做到知识和操作分离吧。。。。。。。

做软件的泡泡