观点描述

普遍认为是“好”的设计原则:

  1. 简单性:在实现和接口中,设计必须简单。接口的简单性比实现更重要
  2. 正确性:在所有可观察的方面,设计都必须正确。一丝的错误都是不允许的
  3. 一致性:设计不能不一致。为了避免不一致性,可以稍微减少一些简单性和完整性。一致性和正确性同样重要
  4. 完整性:实际上,设计必须覆盖许多重要的情况。应该覆盖可能出现所有情况。简单性不可以过度地削弱完整性

“更坏是更好”的设计原则:

  1. 简单性:在实现和接口中,设计必须简单。相对于接口而言,实现的简单性更为重要。简单性是设计中最重要的注意事项
  2. 正确性:在所有可观察的方面,设计都必须正确。正确性的重要程度仅次于简单性
  3. 一致性:设计不能过于不一致。在某些情况下,为了实现简单性可以牺牲一致性,但放弃设计中处理非常见情况的那些部分比引入实现复杂性或不一致性更好
  4. 完整性:实际上,设计必须覆盖许多重要的情况。应该覆盖可能出现所有情况。为保证其它质量,可以牺牲完整性。实际上,只要危害到实现简单性,就必须牺牲完整性。如果保证了简单性,可以牺牲一致性以实现完整性;尤其是在接口的一致性没有价值的情况下

对比两点不同,不难发现“更坏是更好”的要点。其观点几乎可以用另外一句话来概括:“Simple is Best”,但这只是我为了帮助大家理解,杜撰的一句话

经典案例

Lisp和传统的Unix和C语言对比

Unix和C在设计上,充分考虑了实际环境,而放弃了一些一致性和完整性,保证了简单性。这点让C和Unix在历史的选择中胜出。C++也是如此。

David Mertz博士在《XML 问题 #15: 将 XML-RPC 作为对象模型》中,提出的XML-RPC案例也支持了这个观点:

XML-RPC 是一个具有很大价值的远程函数调用协议:它比所有竞争对手都差

与 Java RMI 或 CORBA 或 COM 相比,XML-RPC 可以发送的数据类型很少,而其消息的大小却很庞大

XML-RPC 滥用 HTTP 协议以避开完全有必要存在的防火墙,因此会发送无状态消息并造成通道瓶颈

与 SOAP 相比,XML-RPC 缺少了重要的安全性机制和健壮的对象模型。作为数据表示法,与许多本机编程语言机制(如 Java 的 serialize 、Python 的 pickle 、Perl 的 Data::Dumper 或 Ruby、Lisp、PHP 和许多其它语言的类似模块)相比,XML-RPC 显得缓慢、笨拙且不完整

换句话说,XML-RPC 是 Richard Gabriel 关于软件设计的“更坏就是更好”理念(请参阅 参考资料)的完美体现。对于 XML-RPC,我几乎不能写出比上一段中更生动的描述,而且我认为这个协议非常适合许多大型的任务

后续发展

Rechard P.Gabriel 于1989年最早提出“越差就越好”(worse is better or WIB),后来发展为一种软件设计风格或理念。Gabriel的文章“the Rise of worse is better”中强调软件的简洁和界面

这同MIT approach(or the right thing)的作法形成鲜明对比,后者强调事前完美的设计。由于WIB可快速推出软件应用,并持续完善,故而易于推广

20年来Gabriel反复论证WIB,他最后的结论是自己作主(Decide for yourselves.)

社会化软件flickr和美味书签(delicious)对标签(Tag)的成功应用似乎验证了WIB

Damian Cugley用自己项目经验SeaHorse佐证之。目前研究人员认为自由分类法(folksonomy)不成熟的理由是:缺乏规范、无法控制一词多义和多词同意和多语种的问题。但按照WIB的观点,Cugley认为:

Flickr and del.icio.us wisely give usability precedence over all other concerns, and use essentially the same system….The problems of synonyms, homographs, and localization have been dealt with by ignoring them: the problems are not bad enough to be worth the cost of solving them.

面对大量元数据过分设计而失败的项目,Cugley的结论是“精致和完美不能代表一切”。所以说没有永恒的真理才是真理,但这也是“悖论”

斗胆批语

谁好谁坏,我们往往是在用结果在说话。Gabriel如果不是因为他的公司运营情况不好,可能也就不会得出这个结论。很多事情,是因为做成功的,而不是理论证明成功的

unix+编程艺术学习笔记13+复杂度:尽可能简单,但别简单过了头 http://blog.csdn.net/YEYUANGEN/article/details/6867054