模块化-续

我先从现有的模块结构说起，然后做一个分类和总结，同时预测一下未来的趋势
最初的Fortran语言就提供了各种模块机制【当然，按照现在普遍的认识，不认为它们是模块，不过按照我的看法，它们显然是】。比如Routine，DataBlock等。后来出现了ADT，出现了Object，这些都是模块的具体例子。

例程 主要用于重用一个抽象
数据块 表达用于加工的原材料和结果的一种模块，可以认为是被动的实体
类 用于表达一个概念模型，实际上是数据块以及所有操纵该数据块的例程的综合
组件 实现一个或者数个约定好功能的模块，可以方便的装配成系统，语言无关
进程、线程 一个活动【可以是一个例程】加上其运行的环境或者操作的数据
Lambda 一个纯粹的Routine，其本质是一个映射或者关系，表达输入和输出之间的函数，被称作Pure例程的那种例程就是lambda
Closure lambda加上其环境数据构成closure
Aspect 这是对活动阶段共性的抽象，用来表达一些听起来比较抽象的领域问题。比如：安全性，事务之类的非功能性需求一般都可以方便的用Aspect表达。一个比较切贴的说法是横切的关注点
Service 拥有完整业务逻辑实现的组件
包、名字空间 一个逻辑容器，容纳下一层次的模块或者下一层次的包、名字空间。主要用于条理化的组织模块

上面所有的我识别出来的模块机制，可以按照数据和代码来分类，可以按照是静态的还是动态的来分类，可以按照是容器还是元素来进行分类，可以按照是粗粒度的还是细粒度的进行分类，可以按照是抽象的还是具体的进行分类，可以按照是主要用于重用还是主要用于控制复杂性进行分类。

这样，上面的模块和分类方式就形成一个二维表格
。。。省略。。。

可以看出，很多新的模块形式都只是旧的模块形式改变了粒度而形成的。混合了数据和代码的模块越来越受到青睐，原因是这样能更自然的控制复杂度，简化系统结构。虽然在逻辑上，作为模块逻辑容器的模块不必要，但是在实践上，这样的模块对于表达抽象来说仍然很必要。虽然数据类型的模块非常少，但是，现在主流的分解思想却是分解为数据类型的模块。作为代码类型的模块现在开始慢慢的侵入主流，虽然closure这种代码+数据【以代码为主】可以完整的以数据+()运算【以数据为主】表达，但仍然坚定的侵入主流，这说明语法问题不是一个无足轻重的问题，而是一个相当受到关注的问题。