哪儿来这么多编程范式，就只有抽象和组合这两个动作

最近编程简史系列难产，因为一直在想怎么更好的叙述一下结构化编程运动和其带来的革命性影响。不过这段时间翻阅的资料还是对最近的工作有很大的帮助。

近两个月来我几乎脱离了任何所谓的“框架”，就从最基本的组合对象的过程开始做起，来完成各种任务。这丝毫并没有影响我的开发效率，也完全避免了因为过于笨重的框架带来的启动和运行开销。其中的一部分内容上个月末我整理了一下，就是各位现在看到的 Dependency Injection Made Simple。

同样题目的文章我在几年前也在知乎发布过，当时用了几个简单的例子描述了一下可能和大概的做法，混杂着一些别的内容。这次的经验则是，大部分的编程范式，包括所谓的面向对象编程和函数式编程，只是同样操作的几种不同表现形式。这些具体的表现形式因为他们自身表达结构受限，所以看起来各不相同，实质却都是在把共有的内容抽象出来，利用这些抽象的结构组合成最终执行的程序。

类似的观点我在前面的很多文章中也都表达过，这次则进一步这两个动作在不同表现形式上的统一性。不过很多时候因为现实存在的一些问题，让我们无法比较好的利用这种统一。

一个问题是大部分框架采用了分层的结构，非常容易让人分散注意力到各层级上。而层级本质上是为了做隔离，而非是利于组合。各层之间相互确实分开了，但也进一步减少了发现可能存在的共性。当然硬说也并不是一定如此，但很多时候大家依赖框架提供好的固定结构去做事情的时候就不免掣肘。

另一个问题则更可怕了。出于总所周知的原因，很大一部分人写的代码其实是完全线性的。而且这个线性过程还进一步地延伸自业务抽象中的“线性”。任何业务都被泛化成了CRUD的情况下，也完全没办法在这些线性代码中提取更多抽象。这甚至给人带来了另外一个印象——程序员的工作就是个体力活，用个灵活一点的平台就能代替——没错我说的就是低代码。出现这个现象还有一个原因，那就是基于CRUD的这种线性编写代码的方式相对能够兼容更大的群体，对于某些依赖人海战术来堆叠工作量的公司或者业务来说更方便扩张。（顺便等到积重难返的时候再搞个所谓的重构，挣两遍钱。）

我们再回头来看所谓的编程范式，相互之间似乎非得争出个高下来。但你去细细考虑GoF的那些个结构型和行为型模式，大部分都可以换一种形式用函数式实现。甚至其在运行时的行为都没什么区别。而从灵活性的角度来看似乎函数式更胜一筹但却在一定程度上带来了不少隐式开销，也让我们丧失了对具体结构和行为的操控能力。这些也许不会带来什么严重的问题，在大部分情况下你甚至都不用去考虑，但一旦出现问题，为了饶过他们所需要额外做的操作可就不那么简单了。

幸而我们目前所使用的编程语言都是多范式的。所以目前从我的角度来看，编程范式的概念只是为了能够相互交流所构建的一组语汇。所有的代码无论是否有预先设计，总会在实现过程中发现共性并且随时进一步地提取抽象，或者是利用已有抽象组合出来，至于你提取的结果是一个高阶函数，是一个闭包，是一个其他什么奇怪的结构，那就随你了。