变化的尺度之程序设计

曾经"世界上唯一不变的东西就是变化"是我的至理名言。它也给了我一个生活的哲理，要随时接受变化，随时准备变化。如今，变化成了我最头痛的事情。主要原因就是，随着年龄的增长，感知周围环境变化的能力下降，自身的应变能力也跟着变弱。于是，今天就对这句话进行了重新解读。

变化本身是有尺度之分的。如果将之展现到直角坐标系之中，那么横轴就是这件事物的影响范围，纵轴就是这件事物的变化尺度。最终它展现的犹如一条逐渐增长的幂指数曲线，有时也似一半的抛物线，当然也可以是一条简单的递增直线。每件事物都有自身的变化趋势，甚至事物的每个组成部分亦然。而感知这些变化的则是我们身体的各个器官。并且每个器官感知变化的维度及范围都有限。也就是说，尺度就是变化的维度及范围标定。而尺度的意义就是为了被外界感知。太阳的东升西落对于人类来说是很重要的生存条件，因此，人类自身器官对于太阳变化的感知尺度就是位置及热度的尺度。而太阳对于地球来说是维持自身位置及运行规律的条件，则地球本身对于太阳的感知尺度则不仅是位置及尺度，还包括太阳风，太阳辐射的强度等等。

程序设计模式就是对于程序中变化尺度的一种划分手段。无论是23种设计模式还是OOP的设计思想无一不是在想办法用程序来处理业务逻辑中的变化尺度。比如，有两个模块相对不容易变化，但是两个模块间的组合方法却经常变化，则需要用适配器设计模式来解除两个模块间的耦合。此时，两个模块之间互相感知对方变化的尺度，通过适配器进行了很好的控制。再比如，命令设计模式中，命令的执行模块一旦建立则不容易改变，但是具体执行什么命令却需要变化。而命令设计模式则将命令的执行及构建解耦合，使得命令的构建与执行分离，使得命令的执行模块对命令的变化尺度的感知控制在一定范围，比如命令的类型变化。因此，解耦合出现的原因是一个模块中出现了一部分变化尺度大与变化的感知部分不匹配。解耦合本质上就是模块的分化。因此，耦合过松则沟通效率下降，程序执行效率必定受影响。耦合过紧则需求变化时修改成本升高，程序的设计效率必定受影响。

从变化尺度的角度来理解设计模式就不会陷入到死读书的泥潭。而用好设计模式仍然严重依赖于程序员本身对业务中变化尺度的观察及理解。不过这里可以通过变化尺度来获得几条很方便的技巧。比如，一个功能的正常运行所依赖的东西越少越好；把功能所依赖的外部条件写成定义为接口；观察功能的依赖条件及所依赖的变化尺度是否匹配等等。设计模式原则上要看得出来就用，看不出来就不用。