Thinking in Current Programming Way

 

 

一、我们要解决的问题

• 功能的描述、表达，即功能的实现

• 结构的描述、表达，即功能的组织

• 业务的描述、表达，即最终的目标

二、我们对功能的描述、表达

• 开始，人们用指令封装了电路来表达功能

• 后来，人们用函数封装了指令来表达功能

• 再后来，人们用库封装了函数来表达功能

• 那么现在，我们用什么来封装库去表达功能呢？【问题一】

三、我们对结构的描述、表达

3.1，programming principles

• 开始，人们用文字来描述简单、正确、灵活、高效的有关软件结构的principles，如“模块化”、“松耦合和高内聚”，“抽象和实现隐藏”，“封装变化”等，可是，依然存在不合理的结构

• 于是后来，人们强化了编程语言来支持这些principle，并发明了各种paradigms

3.2，programming paradigms

 

在大英百科全书关于“分类学理论”中提出：人类在认识和理解现实世界的过程中，普遍运用着三个构造法则：

1. 区分对象及其属性，例如，区分一棵树和树的大小或空间位置。

2. 区分整体对象及其组成部分，例如，区分一棵树和树枝。

3. 不同对象类的形成及区分，例如，所有树的类和所有石头的类的形成和区分

• 人们在表达软件的结构方面，已经使用了结构化编程，面向对象编程、函数式编程、泛型编程、及各种产生式编程等

• 结构化编程固化了人们认识世界的第二个法则：区分整体对象及其组成部分

• 面向对象则补充了第一和第三个法则，强化了第二个法则

• 如果分类是正确的，那么似乎面向对象的表达能力已经足够了，为什么还需要函数式、泛型、AOP之类的呢？

• 我们运用一下系统化的思维方式，那么可以发现，面向对象其实是一种“meta paradigm”，而我们日常所说的面向对象其实是“业务空间的面向对象”，泛型和函数式则是“算法空间的面向对象”,而AOP则可理解为“结构空间的面向对象”

• 那么现在，我们最需要什么空间的面向对象？【问题二】

3.3，object oriented principles，idioms，and patterns

• 开始，人们用文字来描述oo paradigm中有关软件结构的principles，如“Liskov替换原则”、“开放封闭原则”、“依赖倒置原则”等，可是，依然存在不合理的结构

• 于是后来，人们发明了各种idioms和patterns，来支持这些principles

• 但再次，idioms和patterns依然只是用文字来描述，如Effective xxx，GOF，POSA，PEAA等，因此依然存在不合理的结构

• 于是后来，人们发明了直接的语言特性来固化各种idioms和patterns，如Java的“synchronized”固化了“scoped lock idiom”，“monitor object”(POSA2)等

• 但被固化的只是少数简单的idioms和patterns，那么现在，我们用什么来固化复杂的idioms和patterns，以消除不合理的结构呢？【问题三】

四、我们对业务的描述、表达

• 做过图形图像领域、做过通信领域、做过信息管理领域，但用的都是同样的或类似的编程语言，而它们都是面向实现的

• 那么，我们应该用什么去直接描述业务呢？【问题四】

五、后模式时代

• 先来看【问题三】，目前主流的思想是非形式化的模式语言，或模式系统，并认为模式的每一次具体实现都可以有略微的变化；这或许是对的

• 但同一个project中，重复的代码段被认为是bad smell，并使用idioms和patterns消除，那么，不同project中，相似或相同的代码段算不算整个软件开发领域的bad smell呢？

• 再来看【问题三】，各种framework做出了另外一种回答，包括.Net和J2EE，而印象最深的，则是loki和spring，便是本身基于各种模式开发，并提供了一个基于模式的开发平台

• loki用模板元编程自动于编译时创建了各种pattern的骨架，基于loki编程，只需要编写特定pattern的单个组成部分，然后作为参数传递给loki，便会得到各种合理的结构

• spring用Java元编程和配置，实现了IoC模式和Interceptor模式（POSA2，AOP便是一种自动化的Interceptor模式的实现），基于IoC和AOP，spring又进一步固化了工厂模式，代理模式，职责链模式，观察者模式等；如果决定使用spring编程，则应该尽量使基础架构基于spring，而不是仅仅在局部使用

• 然而尚有许多模式没有流行的framework将其固化、没有被发现，我们尚需理解模式，并且基于库的解决方案导致我们再次得到【问题一】，那么什么技术能够使模式退居幕后，让我们感觉不到它们的存在呢？或者其实是无处不在，进入后模式时代呢？【问题五】

六、解决方案空间

• 再来看【问题二】，我们最终是要解决问题，因此姑且将最需要的空间称之为解决方案空间，姑且令其包含“描述”和“实现”两部分，姑且将目前的各种paradigm都划作“实现空间”

• 那么如此姑且之后，“描述空间”的面向对象的paradigm该是什么呢？【问题六】

七、最终的几个问题，后编程时代

• 【问题一】， 我们用什么来封装库去表达功能呢？

• 【问题四】， 我们应该用什么去直接描述业务呢？

• 【问题五】， 什么技术能够使模式退居幕后，让我们感觉不到它们的存在呢？或者其实是无处不在，进入后模式时代呢？

• 【问题六】， “描述空间”的面向对象的paradigm该是什么呢？

• 呵呵，莫非是DSL和LOP？