003设计框架的修正——对插件和模块概念的修正

之前我们使用接口来用来链接插件和模块，后来我发现如果这样的话会出现大段的代码重复，也就是说插件起的作用并不大。其次插件的作用并不是用来管理模块而是辅助模块工作，也就是模块提供给插件一些数据，然后插件经过运算返回一些数据。如果用上一篇对插件的设计的话就会导致本末倒置，我们赋予了插件管理模块的能力，既然要管理模块势必会导致模块数据化，这样就要付出额外的成本来维护我们模块，以使我们的模块符合插件的需求。但是旧的设计还是有一些优势的那就是每个模块都可以当数据处理，也就是可以实现嵌套递归的对数据和模块的定义，即模块套模块。由此可见我们的分类还是太过于模糊，因此我将模块再次分为以下几类然后根据他们的特点针对性的做出设计（通过不断的设计我发现通用的设计就会导致使用时候的不方便，针对性的设计就很明显的不具有通用性，因此我选择分块设计每块都是针对这一类的通用设计，而互相之间比较起来就像是针对性设计。）

容器模块：（此模块仅仅会将一个抽象的容器模块作为父类）

        容器模块可以包含其他任何类型的模块，它们的作用是用来管理其他模块为其他模块提供通用数据处理和存取的功能。c#中自带的字典就是这一类模块。容器模块采用常规的模块设计，每个容器模块对外表现都是单独的模块不依赖于其他任何模块（但是可能依赖于插件）。

逻辑模块：（此模块仅仅会将一个抽象的逻辑集合作为父类，即很多个小的逻辑模块可以互相替换，可以结合其他的设计模式）

       逻辑模块用来实现业务逻辑他们本身不能存储其他模块只能存储基本数据类型，以及容器模块。通过容器模块的使用可以间接的包含其他的模块，但是他无法处理间接模块，他只能通过直接引用的方式调用其他模块。他将会依赖于其他模块，所以这种模块在一个工程中尽可能的少一些。

数据模块：（此模块可以依赖抽象的数据，但是此抽象数据并不是模块而是插件里面带的抽象数据）

       数据模块用来定义新的数据结构，其内部不包含任何对数据的处理操作，仅仅包含对数据的基本运算的定义。

数据插件：（仅仅可以处理实现了抽象的数据模块）

        插件不依赖于任何非插件的组成部分，即插件不依赖于任何的模块，同时插件仅仅对自己内嵌的抽象的数据类型进行处理，是算法的集中体现的地方。插件仅仅会对数据进行处理而不进行存储。插件输入一个符合抽象要求的数据将会按照固定的步骤进行处理然后返回给我们一个结果。插件不关心任何具体的数据或者业务逻辑它是抽象算法的直接实现。

流程插件：（流程插件只依赖基本数据类型）

       一种主要给逻辑模块用的插件，将相同的逻辑做成一个流程插件，并将关键流程作为接口强制调用者提供实现。