一个成功的软件系统，往往需要根据需求在不同的系统平台上运行，为了解决系统在多个平台的移植带来的风险，业务架构往往会设计相应的平台适配层来隔离不同平台的差异，如何设计一个易于扩展的平台适配层，是软件设计人员需要考虑的问题。
设计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
在设计框架的时候，我们尽量要考虑到变化，我可能不知道未来是否会变化，但可以一开始就设计出适应变化的架构。
软件设计
摘要: 一个成功的软件系统，往往需要根据需求在不同的系统平台上运行，为了解决系统在多个平台的移植带来的风险，业务架构往往会设计相应的平台适配层来隔离不同平台的差异，如何设计一个易于扩展的平台适配层，是软件设计人员需要考虑的问题。设计1：1: 提供平台接口文件os.h2：定义如下：#ifdef OS1#define OS_Fun OS1_Fun#endif#ifdef OS2#define OS_Fun OS2_Fun#endifvoid OS_Fun();3：通过定义不同的系统宏，这个头文件展开后也就成了对应的平台的接口层。4：业务代码直接调用OS_Fun()这个统一的接口即可。5：该设计只需要一个通阅读全文
摘要: FACADE这种设计模式本身比较简单，核心思想就是外部系统同本系统的需要通过门面来进行通信，这样可以屏蔽业务细节，不管系统内部如何变化，怎么复杂，但是对外系统呈现一个简单的结构。对于软件模块采用消息通行机制的分布式系统，通常的架构设计为底层平台开放模块消息处理的注册接口，各个模块将自己的消息处理函数进行注册，我们可以把这个消息入口看成子系统的一个门面，所有的发往某个模块的消息都通过注册的消息处理函数来入口void ModuleMsgFun(){ switch(sendModule) { case module1: TODO... .... case modulen: TODO... }}这个M阅读全文
分类: 软件设计
