程序架构思考

程序架构_1

可以将程序分为3部分，一个是逻辑（Logic）；一个是控制（Control）；数据结构（Data Structures）。逻辑是用来解决实际问题的，也就是具体问题的实现。控制是将多个逻辑组合起来工作的方式，即逻辑组合的策略。数据结构是计算机中存储、组织数据的方式。程序运行的效率取决于这三者的组合结果。

如果将逻辑与控制有效的分开，那么给代码带来的是更好的维护性与扩展性，也就是更强的生命力。这也就是我理解的最程序架构设计的基础目标。

数据结构不是不重要，是我理解不够，暂不做过多说明。

编程的本质

1976年，瑞士计算机科学家提出，《Algorithms + Data Structures = Programs》 ，即 算法 + 数据结构 = 程序。

1979 年，英国逻辑学家和计算机科学家 Robert Kowalski 发表论文 Algorithm = Logic + Control，即 算法 = 逻辑+ 控制。

总结上面俩个公式可以得出：程序 = 逻辑 + 控制 + 数据结构

我们写的初始代码大多是逻辑与控制区分不那么明确的，里面数据结构和流程是跟业务相关的，有些是不相关的。业务需要决定了逻辑的复杂度，业务复杂的逻辑本身就会复杂。但是我们可以通过多层级的多维度的切分，将复杂系统实现的更具有可读性。在通过恰当的设计模式更合理的设计多模块的交互接口（也界定了接口交互数据结构）。进而就有了对应特定场景的架构。

实践应用

代码复杂度的原因：

• 业务逻辑的复杂度决定了代码实现的复杂度
• 业务逻辑与控制逻辑的解耦成都决定了系统的扩展性与可维护性

显然，上面的业务逻辑我们是控制不了的，我们可以努力解决的就说解耦业务逻辑与控制逻辑。解耦控制与业务我们可以使用下面的技术：

• 状态机（State Machine）

  • 状态定义
  • 状态变迁条件
  • 状态的动作（Action）

• 某些特定领域（domain）设计的专用语言(DSL —— Domain Specific Language)

  • HTML，SQL，Unix Shell Script，AWK，正则表达式……

• 范式编程（是某种编程语言典型的编程风格或者说是编程方式）

  • 面向对象：委托、策略、桥接、修饰、IoC/DIP、MVC……
  • 函数式编程：修饰、管道、拼装
  • 过程化（命令式）编程