来自陈皓的专栏<左耳听风> https://time.geekbang.org/column/article/2751
Programs = Logic + Control + Data Structures
文中首先介绍了2个公式Programs = Algorithms + Data Structures和Algorithm = Logic + Control, 也就推导出Programs = Logic + Control + Data Structures. 但是, Logic, Control, Data Structures到底对应实际编码的什么部分呢?
对于Data Structure, 大家没有太多异议, 是定义数据存储的结构, 例如数组, 链表, 树等, 本文也没有太多描述. 那Logic和Control是如何区分的呢?
Logic是业务逻辑, 往往与需求直接相关. Control是解决问题的策略, 是达到业务逻辑的具体路径. 举个例子, 阶乘, X(n)! = X(n) * X(n-1) * ... * 3 * 2 * 1, Logic是定义阶乘, 1) 1是0的阶乘; 2) 如果v是x的阶乘, 且u = v * (x+1), 则u是x+1的阶乘. 有点像数学概念的定义. Control是过程, 可以从上往下将x+1的阶乘缩小为先计算x的阶乘, 再将结果乘以x+1(递归), 也可以先计算1 * 2, 再乘 3, 一直乘到x+1(循环).
Control是可标准化的, 如: 遍历数据, 查找数据, 多线程, 并发等. 联想到平常的开发工作, 如MVC模式就是一种Control, 它定义了数据流转的方式, 与具体的业务逻辑没有太大的关系. 还有平时做的一些性能优化, 基本也都是Control, 它改变了程序占用内存, 执行时间等, 但不会去改变业务逻辑.
有效地分离Logic, Control, Data是写出好程序的关键
回忆下自己初学程序时, 写的杂乱无章的代码, 一些坏习惯, 比如:
- 一个方法太长, 占几百行
- 一个变量使用多次, 有多重含义
- 大量的for循环嵌套, 大量的if else嵌套
这些代码, 有以下缺点:
- 可读性差. 很难理解真正的业务逻辑是什么, 读懂全靠debug.
- Bug多. 这些代码只能保证基本的运行, 往往还包含大量的Bug
- 难以修改. 代码之间的关系贴合的过于紧密, 导致很难修改.
究其原因, 往往将Logic和Control混合在一起, 杂乱无章. 好的代码应该将Logic, Control, data分离开. 这里推荐一种数据编程的概念, 将Logic转化为metadata, 如定义好的列表, 再对这个metadata实现一套通用的控制逻辑, 用以实现业务逻辑. 可参考数据编程https://coolshell.cn/articles/10337.html.