人心中的成见是一座大山，数据转换思想

https://github.com/rainforesters/imsure 一直在用，确实好用，已经离不开了

https://github.com/rainforesters/imsure-demo

上周发了一个主题后评论区颇为热闹，就用此文统一回复下吧。我不想争论是非，只是我觉得这个理论就像日心说一样值得被更多人知道，应该被更多人知道，哪怕它和日心说一样被证明是错的，也算挣脱了思维桎梏，启迪了方向。若值得在茶饭之余引发讨论就更好了。

程序的本质是数据转换，那么逻辑过程的意义可以一概视为根据 input 转换为 output ，所以我们可以试着改变一下程序的编写方式，

从：

f(input) ⇒ output

进化为：

output ⇐ Watch_transform(input)
Rule = Watch_transform
output ⇐ Rule(input)

为了让观察转换变得可行，我们把 input output 作为字段都定义在抽象的 Struct 类型上，

那么就得到了：

self.output ⇐ Rule(Struct.input)
self 是 Struct 的实例
Rule 就可以在 self 未实例化之前，提前定义在抽象的 Struct 类型上；同时也允许 input output 在 Struct 的不同层级

这就变为了纯粹的数据转换链。只要依赖的 input 更新 output 也会随之更新，整条链也随之更新到最终稳定状态，既简单又保证了确定性。在转换链中，每个节点只干一件事，只需观察依赖的前置数据而不必考虑后续自己会驱动谁或被谁所依赖，彻底摆脱逻辑控制流。

这种写法就像从算术方法到方程解法一样具有普适性。
从传统编程需要根据不同业务需求设计不同的实现过程，到全然不用设计，只套用一条普适的方法就行：

定义数据结构。（设未知数）
定义转换规则。（列方程式）
为字段赋值。（代入已知数）

至此，就再也不需要推导业务逻辑了。

若你看懂了以上内容，那这段自不必说，若没看懂请继续。

传统逻辑过程可以细分为两部分：

先把将要进行转换的 input output 建立关联。
然后进行转换，纯粹的转换算法。

传统写法下 80% - 90% 的代码都在建立关联、维护关联，其实转换算法的代码很少很少。
新写法中建立关联就像呼吸一样简单。

ZiChun

210 天前

@muchan92 “不必强用这种写法来实现”，“更适合解决实际中的业务内容”，这已经说明了这种思路的局限性。你要知道，程序员写代码不是为了自己的精神愉悦（更何况这个设计也没办法让大家精神愉悦，当然或许有人觉得这么设计很“高级”吧），要兼顾开发速度、代码质量、维护难度。按照这个仓库里的这种写法，新招进来的员工都骂，出个问题排查半天，性能远不如普通的设计，我没有清楚你推崇这种设计思路的点在哪儿，本身“实际中的业务内容”就不是一个需要解决的痛点，有数不清的方式做。