我理解的声明式 vs 命令式

按照官方的定义，声明式编程（英语：Declarative programming）是一种编程范式，与命令式编程相对立。它描述目标的性质，让计算机明白目标，而非流程。 在《声明式编程：by example》一文中，我也举了一个报价 API 设计的例子来说明两者在设计范式上的区别，以及我们为什么要追求声明式。但是很多同学可能还是对两者之间的差异比较困惑。

从深层次来看，命令式和声明式编程不是两种设计技巧的比拼，而是两种设计理念的碰撞。

第一，对于受众而言，相对于命令式编程，声明式是更使用友好的。一个人了解目标比了解一个领域的细节更容易。就好比我们知道需要使用什么功能的 app，但是如果要求对 app 构建的细节都了解就有些勉为其难了。在这点上，声明式编程可以很好的屏蔽内部的细节，对使用者来说更友好。

第二，在产品理念上，声明式编程是系统性的，而命令式是还原论的。声明式编程可以让设计者更全面的、通过不同视角去看一个产品，而不像还原论一样，只是从技术拆解的视角去看待产品。所以对于产品经理，用声明式去反应产品理念，会是一个比较好的途径。

第三，在架构设计上，相对于命令式编程，声明式是更粗粒度的。声明式编程只是描述最终的目标，而不关系具体的步骤。所以相对于命令式，声明式会是相对粗粒度的。这种粗粒度往往可以很好的将目标聚类，而不会陷入于细节的泥沼中。

第四，在实施上，声明式编程会是另外一种方式能力的输出。声明式的接口设计往往需要通过 DSL 的方式体现，就好比 SQL。这种 DSL 的出现，可以认为是另外一种 Context bondary 的解决方案。

最后，声明式更具艺术感，而命令式技术感更强。有大量实践经验的架构师都会体会到，声明式的设计，往往没有一个对错之分，而在于美丑。一个声明式的接口，不断的思考，都会看到存在优化的空间。比如还是对于报价服务的设计：

• 第一版本可能会体现蛮多的外汇专业性，比如币种对、比如交易币种、比如买卖方向。

• 通过使用实践以及收集小白的问题后，第二版的设计可能会把这些都抛弃，只是需要使用方给出买入和卖出币种金额，返回一个汇率对象。

• 第三版，考虑到返回汇率之后，用户还需要计算，可能最终的版本是：输入买入和卖出币种和单边金额，给到汇率和 contra 金额。这个就妥妥的一个 DSL 了。