README.md

# zcmf-zero_coupling_module_framework

这是一个零耦合的模块工程架构。模块间的交互操作以string作为key，通过静态存储区进行交互，从而达到所有模块均不互相依赖的目的。该架构适用于多任务并行执行，并且多有交互的情景。

## 框架背景以及原理

有时候，我们会因为功能的划分，将一部分内容拆分成多个模块，但是由于其内部有具有一定的关联性，如相互之间的函数调用等。在单独编译各个模块的时候，仍然需要对方的头文件，以及运行时对so的依赖。这样的一种设计，我们称其为耦合设计。通常情况下，我们并不喜欢这种强制的耦合关系，它导致我们的系统依赖关系复杂，不够灵活。

所以，产生了很多低耦合，零耦合的设计，而我们的框架也是其中一种。

我们框架的最基础原理是巧妙地利用了，同一个线程具有相同的静态存储区的性质，在这块相同的区域内支持各个模块的请求与响应，从而做到各个模块间的通信。这样做的好处是，在编译时，其他模块间都不需要相互依赖了，仅需要依赖基础的头文件即可。在运行时，不会去检查对方的so是否存在，而是启动后，去静态存储区查找，如果查找无果，则通信失败。

在框架中，我们提供了一种服务机制，一种消息机制。

服务机制介绍：服务由一方提供，并将其函数地址存储在静态存储区，任意模块（包括自身）都可以作为客户从静态存储区中获得该地址，补充适当的参数即可运行。
消息机制介绍：消息由一方订阅，一方推送(可相同)。订阅方提供消息处理函数，推送方直接将消息推送出，并触发消息处理函数（可以是多个）。

不同点：处理函数的实现位置是不同的，可以引用的类成员变量也是不同的。
相同点：实际上都是在客户或者推送方去提供参数，调用处理函数执行的。


## 框架现有的功能

1. 服务机制
   服务机制和消息机制在messager中实现, 具体介绍参见[点我](code/src/corelib/include/message/README.md)
2. 消息机制
   同上.
3. 模块线程管理基类
4. 统一的log接口
5. 进程CPU 内存实时记录
6. 时序ulog存储
7. 日志落盘
8. 类似与电信号中断机制的信号诊断功能 

## 框架后续的发展规划

1. 框架中仍然有部分逻辑过于复杂，后续考虑进行简明化
2. 框架中仍然有部分的效率没有做到最高，后续考虑更好的优化策略
3. 框架中缺少一种自定义的异常处理机制
4. 框架中缺少单元测试模块
5. 线程调度方面有待完善
6. 获取上一条已输出日志的接口,用于自测时

## 本文使用的术语

| 编号 |   术语和缩写 | 解释 |
| --- | ---------  | -----|
| 1   | 模块 | 用于描述一个整体功能模块, 通常模块内都会有一个pulgin.cpp文件,去控制模块的启动和停止|

## 框架使用建议

1. 尽量不要自启线程, 框架内包含对线程的调度部分, 可以满足大部分需求.

## 特殊情况使用指导

### 1.单个模块需要阻塞调用

有时,我们会使用到someip ros这类的通讯机制, 其主要通过回调函数完成, 但是都需要调用一个阻塞线程, 用于监听. 这时, 建议不要在模块内自启线程, 而是直接让阻塞线程在 thread_func 函数内阻塞住. 同时, 重载基类函数stop,  实现阻塞线程的退出.


[111](code/src/corelib/include/pipe/README.md)