插件式模块化软件框架的思想图解二(案例篇)(码客卢益贵)

插件式模块化软件框架的思想图解二(案例篇)(码客卢益贵)

关键字:插件化 模块化 软件框架 C++ Golang Rust Delphi

目录

一、前言

二、框架总图

三、模块划分

四、配置及资源文件目录结构设计

五、对象的个性化派生设计

六、源码文件目录结构设计

七、数据交换机设计

八、最终效果图

九、后话


一、前言

本人推崇模块化设计,不是基于技术深度而是基于管理高度(如何在多变的项目需求中提高开发效率、缩短开发周期)。本文将通过一个《火车在途实时信息系统》的火车实时和历史轨迹显示部分的简要阐述来“插件式模块化软件框架思想”的理解和应用(实际项目设计要复杂得多)。

本文涉及项目截图均已向社会公众公开,本文仅阐述行业惯例或通用做法部分,不涉及商业秘密和专利核心技术。

阅读本文前最好先阅读本人上一篇博文《插件式模块化软件框架的思想图解一(框架篇)》:

https://blog.csdn.net/guestcode/article/details/119701789

二、框架总图

为保证文章完整性,借用《框架篇》的框架总图。

插件式模块化软件框架的思想图解二(案例篇)(码客卢益贵)_第1张图片

三、模块划分

按业务需求的功能大类划分,功能模块划分好了,再去设计基础模块如何为功能模块提供服务,再深入设计“业务框架”。我把项目划分为“实时监控模块(MonitorRealTime)”和“历史数据查询模块(QueryHistory)”等若干模块(命名是为了排序需要,无关英文语法),仅举例两个模块就不作图了。

实时监控和历史轨迹都要显示火车头和轨迹信息,具体业务需求是:实时监控时火车轨迹图标是红色,历史查询时轨迹图标是蓝色,两个模块的火车头图标颜色相同

四、配置及资源文件目录结构设计

配置及资源文件有:电子地图图层文件、素材图标文件、参数配置文件等。电子地图资源的加载需要依赖一个叫“GisMap.cfg”的配置文件,加载一个资源文件需要配置一行相关参数。原Gis系统的要求是统一配置在一个多行文件里,我做了特别处理:按模块需求分多个文件配置。

基础图层的配置信息放在公共目录处:/ResCfgs/Comm/TrainGisMap/GisMap.cfg。火车头图标的配置信息放在基础模块目录处:/ResCfgs/MuduleBase/TrainGisMap/TrainHead.cfg。红色和蓝色轨迹图标的配置信息放在功能模块目录处:/ResCfgs/MuduleFunc/MonitorRealTime/TraceRed.cfg、/ResCfgs/MuduleFunc/QueryHistory/TraceBlue.cfg。

这样,资源配置部分也满足了模块高度独立的原则要求(关于模块化原则和业务模块共性与个性划分请参阅《框架篇》),确保了模块配置文件目录删除不留残余(这在版本迭代时不会导致代码残余积累,也不会因为误删导致系统崩溃)。

插件式模块化软件框架的思想图解二(案例篇)(码客卢益贵)_第2张图片

五、对象的个性化派生设计

根据模块需求,对对象进行了个性化划分,作为最上层(图形最底层)的功能模块对象,即使这个模块删除了不会影响该对象父类被其他模块使用,也不会因为删除而留有残余在父类

插件式模块化软件框架的思想图解二(案例篇)(码客卢益贵)_第3张图片

六、源码文件目录结构设计

目录设计思想(模块目录独立)可参考《框架篇》的模块化原则和目录总图。

插件式模块化软件框架的思想图解二(案例篇)(码客卢益贵)_第4张图片

七、数据交换机设计

类似消息中心有订阅、通知功能,但和消息中心不同,消息中心是简报形式,数据交换机是大数量的信息交换中心。

我们处理的数据有GPS轨迹数据和火车黑匣子数据,每项数据的都用唯一字符串Key来定义,向数据交换机注册数据类型的时候,数据交换机会转换成整形值,避免了高频情况下字符串处理的低效率问题。

在这个机制下,GPS和黑匣子这两个数据处理模块的代码任何一个或者全部移除,都不会导致系统崩溃,也就是当数据消费模块(持久化和监控模块)主动向数据交换机获取数据的时候返回结果是0而已。

在中后期的持续调研中发现,火车安装的黑匣子有多个厂家的且同一个厂家还有不同型号,于是我们基于原有的模块接口标准,在不改变原来的任何代码情况下,针对不同型号的黑匣子做了N个型号的黑匣子数据处理模块(插件),系统在运行时自动识别黑匣子型号并自动插入相应的数据处理模块(插件),并且可以进行热拔插(切换)不影响系统运行

插件式模块化软件框架的思想图解二(案例篇)(码客卢益贵)_第5张图片

八、最终效果图

插件式模块化软件框架的思想图解二(案例篇)(码客卢益贵)_第6张图片

实时监控图(红色轨迹)

插件式模块化软件框架的思想图解二(案例篇)(码客卢益贵)_第7张图片

历史数据查询图(蓝色轨迹)

九、后话

插件模块化不一定适用所有项目或者项目中的所有功能,但按82法则,满足80%的业务需求就足够了。先不说后期维护,在多人协同开发时,制定接口规范之后个人就可以独立自主开发,在开发期能避免更多的沟通成本。

你可能感兴趣的:(All,我的文章,软件工程,其他)