原文来自
非典型秃子
对
江南白衣
blog文章《
Javaer 双修C++的key point
》的回复：
"在C++设计过程中，通常，我们会在两个角色之间转换：生产程序员和客户程序员，我们需要保持两种角色之间衔接的简单性。例如，STL的实现，可以很复 杂，但是，必须保持使用上的简单性，要足够简单。为了实现这种使用上的简单性，在STL的实现上合理运用高超的技巧，就是值得的－－这种复杂性不会扩散。 如果STL的内部实现简单了，但是代价是接口或者使用的时候的复杂，那么这种简单就是有问题的。
一种复杂性，导致了整体的简单性，就是有益的，反之，则是有害的。 判断一种复杂性是不是可以采用，我的标准是：如果这种复杂性不会扩散，那么，可以大胆一点，如果会扩散，那么就需要谨慎。 我想，这样比简单的回避复杂性更有效。
当然，复杂性是手段，不是目的，我这里并不是鼓励卖弄技巧和试验复杂方法，只是在简单方法不能完成任务时，不妨试一试所谓的复杂方法。"
"在C++设计过程中，通常，我们会在两个角色之间转换：生产程序员和客户程序员，我们需要保持两种角色之间衔接的简单性。例如，STL的实现，可以很复 杂，但是，必须保持使用上的简单性，要足够简单。为了实现这种使用上的简单性，在STL的实现上合理运用高超的技巧，就是值得的－－这种复杂性不会扩散。 如果STL的内部实现简单了，但是代价是接口或者使用的时候的复杂，那么这种简单就是有问题的。
一种复杂性，导致了整体的简单性，就是有益的，反之，则是有害的。 判断一种复杂性是不是可以采用，我的标准是：如果这种复杂性不会扩散，那么，可以大胆一点，如果会扩散，那么就需要谨慎。 我想，这样比简单的回避复杂性更有效。
当然，复杂性是手段，不是目的，我这里并不是鼓励卖弄技巧和试验复杂方法，只是在简单方法不能完成任务时，不妨试一试所谓的复杂方法。"
兽评：在复杂性和简单性之间存在着这样一种辨证关系，有时候为了提供简单性的接口，我们需要采用异常复杂的技术。对复杂性的控制与管理是软件开发的一个重要的特征，控制复杂性的扩散是一种必备需要。西蒙有一个很好的比喻：从前有两个钟表匠，名叫坦帕斯和霍拉，他们能制作出精美的手表－－每个手表都有大约1000个零 部件。坦帕斯在制作手表的时候，如果放下手中的活－－譬如去接电话－－手表马上会散架，必须重新从头组装那些零部件。顾客越来越喜欢他做的手表。给他打电 话的次数越多，对他来说找到充足的，不间断时间完成一个手表就越难。 霍拉制作的手表不比坦帕斯制作的手表复杂程度低，但是他事先做好设计，这样他就能够将十几个零件构成组件，然后组合这些位置固定的组件。因 此，当霍拉放下手中正在组装的手表去接电话的时候，他只错过一小部分的工作，他可以仅用坦帕斯所用工时的一部分就完成手表的组装－－如果这两个手表匠在安 装零件时每10次有一次被打断，那么平均来说坦帕斯完成一只手表所需的时间是霍拉的4000倍。
本文转自xiaotie博客园博客，原文链接http://www.cnblogs.com/xiaotie/archive/2006/05/18/402990.html如需转载请自行联系原作者
xiaotie 集异璧实验室(GEBLAB)
