独望枫

代码结构理清, 章程已经文档化, 工程环境已经规定好, 不着手工程开始干活, 简直对不起之前花费心血准备的种种.

首先, 由于提取出来的基类, 以源码的形式存在并导入到各个模块, 所以必须要将其实现导入到模块工程里面, 而对应的头文件可通过vs的环境配置包含进来, 所以需要增加一个base的筛选器:

其次, 上文提到的, 关于部分各个模块各个类都需要使用到的函数被抽取到一个对应的工具集函数里面, 并且也是以源码形式存在于各模块工程, 所以同样增加一个tutorial的筛选器:

接下来就是关键的模块工程:

一、二、三、四、五个类? 对比前文的规划后的类图, 不是少了interface这一块?

本系列第一章提到, interface的主要负责模块对外的接口, 重整之后, 将interface彻底跟模块的业务逻辑分离, 原本由interface全局变量串联其他四个类(module/ui/param/driver)的工作, 在之后将完全被mediator所接管.

所以, 这里可以体现出一点关于增加多一个mediator类的用途:

1.mediator则承担了原本由interface调度的业务逻辑, interface单纯只负责对外接口的处理, 可以将interface跟模块的业务逻辑完全解耦.

2.往后如有业务需求在整体架构不变的情况下, 业务主体逻辑可以整体移植过去, 主要修改对应的interface部分即可.

最终完整的工程配置如下:

其中"头文件""源文件"都是按照工程建立时可自动生成的, 后面主要将interface部分在这里处理一下即可.

其他模块所有的源文件和头文件都按照各自的定位分好类, 存在于各自的筛选器中.

这里面的基本思路是:按照不同的定位处理好对应的依赖关系, 在源文件更多的情况下, 这个分类很有必要.

最后总结一下, 调整后的工程配置的优缺点:

优点:

1.按照不同的定位区分

2.从代码与工程配置上都将业务逻辑主体跟接口分离

3.方便以后的移植

缺点:

1.相关文件路径的配置麻烦

2.总体工程的观感上比之前要有更多内容

配置上的麻烦是一时的, 主观上的感受是可以被改变的, 配置界限分清之后, 对后面增加的测试更有大大的方便.

未完待续...