12月09日 15:04 "weidagang2046"的内容
推荐一篇FP的文章，里面对FP的优势做了很好的介绍。在OO语言中也可以借鉴一些FP的风格改进设计。/erain/archive//12/14/1354810.html
彻底受教了，不过对这篇文章有不敢苟同之处：
之前一段试图将数学哲学化很让我反感，这是典型的泛数学主义思想，数学之外还有一个艺术，不是所有事物都可以量化数学化，如果可以，如今就不存在那么多未知领域和疑惑，也不能认为混沌结构思维毫无用处，中国人靠中医活下来了，活得不差。这是灌水，不多说。
用currying说明设计模式就不需要使用，这也只是一厢情愿(GoF设计模式三作者后再谈模式)，算法数学占据主要地位大概只有特定算法科学领域，现实的胶水模块领域，还必须注重架构和模式，在DDD中有一段对算法观点：
1.算法或计算非常复杂，导致设计受到了冲击，模型中的概念变成了用“怎么做”来解释，而不是用“是什么”表达。(主次颠倒)
2. 算法本身存在内聚性(因为它能用公式表达，公式就是算法具有内内聚性的特征)，使用策略模式等框架把这些内聚计算分离出来，用一个明确接口来说明这个框架的功能，将怎么做复杂细节交给框架(主要管算法的API)去完成。
3.我们计算方法不可能把所有功能都包含进来，我们需要的也不是一种万能计算机制。(批评那种算法万能观点，没有一个算法能够把万事万物功能算进来，如果是，就成了周易算命了)。
在DDD中将副作用也就是边界影响归纳为柔性设计，所谓柔性实际就是艺术性的事情，这是架构的目标，DDD认为柔性设计为：
1.明显意图的接口：面向接口编程，做什么目的在接口中清晰表达，而无需翻看具体代码。
2.边界影响： 消除边界影响，不要搞一机多能。
3.粒度适当界定 粒度不能太大，造成重复和冗余，很多概念混在一起；当然粒度也不能太细，以至于太碎，不能完整表达一个领域概念。高聚合、低关联。
4.消灭依赖 每复杂的依赖关系无疑提高了系统的复杂性，每个依赖都是值得怀疑的。
5.操作封闭 服务行为操作的是同一个类型，不要一次性处理多个模型。
6.声明性设计，尽量使用成熟框架，保证质量。 如DSL
可是这些这篇文章中用轻飘飘一句：“因为 lambda 演算不是被设计为在物理局限下工作的。因此，象面向对象的编程一样，函数式编程是一系列理念，而不是严格的教条，”这其实就是柔性艺术性的特征，由于作者背景知识原因没有认识到罢了。
所以，函数式编程和OO不矛盾，而且是在OO世界中属于一个“怎么做”的问题，而OO方法论如DDD是解决把“是什么”和“怎么做”如何分开。
说得详细一点：“是什么”就是需求是什么，先要把需求说清楚，功能要求说清楚；“怎么做”是如何实现问题，通过软件技术架构或算法等等科学来实现。
btw:由于我们都是在学“怎么做”中长大的，忘记“是什么”这个主要目标，就容易造成井底观蛙，舍本求末，南辕北辙，这实际是为什么当前科学总是不能转化为生产力的原因之一。
以上只是个人想法。
[该贴被banq于-12-09 16:29修改过]
