编程的一些抽象核心

一、程序、算法

本质

程序=算法+数结结构
算法=逻辑+控制

程序=算法+数结结构，这个是众所周知了，算法这个解释则比较清丽脱俗：1.逻辑 2. 控制。

• 逻辑用来解决实际的问题， 控制决定用什么策略来解决问题，逻辑是真正意义上的解决问题的算法
• 控制是一个程序流转的方式，即程序执行的方式，并行还是串行，同步还是异步，调度不同执行路径或模块，数据之间的存储关系。

逻辑是是处理什么，控制是怎么做，沟通方式是数据结构

举例

表单验证经常的做法是

function check(data) {
    名字 = get(data, 名字)
    if (名字为空 || 名字长度小于3) {
        return 验证失败，名字非法
    } 
    密码 = get(data,密码)
    if (密码为空 || 密码长度小于8) {
        return 验证失败，密码非法
    } 
    邮箱 = get(data,邮箱)
    if (邮箱为空 || 邮箱格式不正确) {
        return 验证失败，邮箱非法
    } 
    ...
    return 验证通过; 
}

这个函数最终逻辑是验证输入数据的合法性，但是这样其实就是把控制和逻辑耦合在一起了，随着验证字段的增多，这个函数会越来越长，最终造成可读性越来越差，越来越难维护

更好的分离两者的方法是，定义一个表单验证器，如下

var rules = {
     名字: ["长度大于3"],
     密码: ["长度大于8"]
     邮箱: ["email格式"]
    ...
    ]
};
 if 失败结果=checkRules(rules).执行(); 失败结果不为空 {
    return 验证失败，失败结果
}
return 验证通过 

这样通过描述验证规则，得到了一种控制和逻辑之间的解耦，不用再在check里边各种if else了。

绝大多数程序复杂混乱的根本原因是业务逻辑和控制逻辑的耦合

二、面向对象、设计模式

面向对象、设计模式的重点就是：

• 使用接口抽象了具体的实现类，这样其它类耦合的是接口而不是实现类，这就是多太，增加了程序的扩展性
• 接口也就是一种协议，就像HTTP协议一样，浏览器和后端的程序都依赖于这一种协议，而不是具体的实现（如果是依赖具体实现，那么浏览器就要依赖后端的编程语言或中间件了，这就太恶心了）。于是，浏览器和后端的程序就完全解除依赖关系，而去依赖一个标准的协议了，这也是Ioc/DIP的本质。

23个设计模式基本就是说了两个面向对象的核心理念：面向接口编程、组合优于继承

面向接口编程

• 使用者不需要知道数据类型、结构、算法的细节
• 使用者不需要知道实现细节，只需要知道提供的接口

组合优于继承

继承需要给子类暴露一些父类的设计和实现细节，父类实现的改变会造成子类也需要改变，而组合则不存在这样的弊端。
我们以为继承主要是为了代码重用，但实际上在子类中需要重新实现很多父类的方法，继承更多的应该是为了多态。

三、依赖倒置和控制反转 （IoC/DIP）

简单说就是要依赖于抽象接口，不要依赖于具体实现
这就是控制反转，开关从以前设备的专用开关，转变到了控制电源的开关，而以前的设备要反过来依赖开关厂声明的电源接口

钱

从以前的以物易物，变成了依赖“钱”，所有的商品都依赖这个“钱”的交易协议，不用再互相依赖了，整个世界的动作就简单了很多

开关和灯

有一个开关要控制一个灯的开和关，最直接的方法就是把开关和灯做到一起。
但是，如果有一天，我们发现这个开关可能还要控制别的不仅是灯泡的东西，就会发现开关耦合了灯泡这种类别，非常不得扩展。
解决方案就是，造开关工厂根据不需要关心要控制的东西是什么，只做一个开关，功能就是把电接通和断开，不管是手动的、声控的还是光控、遥控的，开关厂和电灯厂依赖于一个标准的通电和断电的接口。
造灯泡的工厂也不关心你用什么样的开关，只管把灯的电源接口做出来，开关厂和电灯厂依赖于一个标准通电和断电的接口。

证券交易所

在交易的过程中，卖家向买家卖东西，一手交钱一手交货，基本是要见面的，这个时候银行出来做担保，买家先把钱打到银行，银行让卖家发货，买家验货后，银行再把钱打给卖家。
这就是反转控制，买卖双方把对对方的直接依赖和控制，反转到了让对方来依赖一个标准的交易模型的接口。