一个成功的软件系统,往往需要根据需求在不同的系统平台上运行,为了解决系统在多个平台的移植带来的风险,业务架构往往会设计相应的平台适配层来隔离不同平台的差异,如何设计一个易于扩展的平台适配层,是软件设计人员需要考虑的问题。
设计1:
1: 提供平台接口文件os.h
2:定义如下:
#ifdef OS1 #define OS_Fun OS1_Fun #endif #ifdef OS2 #define OS_Fun OS2_Fun #endif void OS_Fun();
3:通过定义不同的系统宏,这个头文件展开后也就成了对应的平台的接口层。
4:业务代码直接调用OS_Fun()这个统一的接口即可。
5:该设计只需要一个通用的接口文件和对应不同平台的实现文件。
设计2:
1:提供平台接口文件os.h,并且提供一个平台的接口实现文件os.c
2:os.h定义如下:
void OS_Fun();
3:os.c定义如下:
#ifdef OS1 #include "OS1.h" #endif #ifdef OS2 #include "OS2.h" #endif #ifdef OS1 void OS_Fun() { OS1_Fun(); } #endif #ifdef OS2 void OS_Fun() { OS2_Fun(); } #endif
4: 通过定义不同的系统宏,源文件对应不同的平台实现。
5:业务代码直接调用OS_Fun()这个统一的接口。
第一种设计看起来更加简洁,所有的适配都在一个头文件里面搞定,问题是第一种设计扩展性好吗?笔者曾经遇到一个项目,平台提供一个消息发送接口,本 系统的所有消息发送都需要调用这个接口,在原有系统上都运行的没问题,但后来需要切换平台,由于两套系统的具有不同的大小端模式,这就要求我们对所有出口 消息进行大小端转换,如果用第一种设计方式,处理起来就比较麻烦了,就算想办法解决了,但也破坏了原有的设计思想。用第二种设计方式我们只需要在适配层加 一个统一大小端的处理函数即可。
#ifdef OS1 void OS_SendMsg() { HTON(); OS1_SendMsg(); } #endif #ifdef OS2 void OS_SendMsg() { HTON(); OS2_SendMsg(); } #endif
在设计框架的时候,我们尽量要考虑到变化,我可能不知道未来是否会变化,但可以一开始就设计出适应变化的架构。
时间: 2024-12-12 05:58:36