设计回顾

近段时间要修改CCServer，使其支持新的交换机。经过对接口、框架的一番巨大调整后，方才结束。由此回想了一下，当时为何如此设计，发现以前的不少问题。

1、为何采用单个EXE调用多个DLL的方法？

问题：用DLL，存在一些静态变量、静态指针不同的堆副本问题，增加了额外的工作；

希望的解决方案：多个EXE，在安装时自动更改EXE的名称。可扩展性不会有影响。

当时的考虑：当时做这个决定时，似乎没有仔细考虑这个问题。

2、为何要考虑在一个EXE中支持多个设备？

问题：需要考虑消息分发，多个设备各自双备，各自状态管理，何时连接RCC等问题。复杂度提高了很多。

解决方案：每个EXE只支持一个设备，可以简化以上处理。并且对于设备控制更为方便。减少很多不必要的代码。

当时的考虑：支持多个设备好像没有什么问题，没有过多考虑其它的方案。

3、为何采用Bridge模式来实现各种设备对外的接口

问题：该接口设计需要随着抽象设备接口的改变而变化，需要完成更多的修改；

希望的解决方案：去掉这一层接口，直接对外提供抽象设备接口

当时的考虑：将设备状态处理完全在这里实现，并提供了设备消息接收线程，使之更接近一个独立的设备。没有考虑设备接口不问题的情况

4、设备接口设计过细，不够抽象和基本

问题：设备数据是变化较大的地方，接口中不应做任何具体描述，只应该给出接口进行访问就可以了。双备的接口也不应该放在底层接口中，应从底层设备接口派生出来。

当时的考虑：没有仔细分析接口的层次，需要隐藏的数据或方法

总结一下，主要有以下几点值得注意：

1、在前期设计时，偏重于将设计做出来，没有考虑为什么要这样做。

2、设计时，没有针对实际的具体要求来进行设计。在设计时过于理想化，希望CCServer设计为功能超强的组件，设计某个部分是过多的考虑复用性，脱离了其实际的要求。

敏捷方法中的“只要满足要求就行”的思想需要好好领会。

3、接口设计做的不够细致，没有从数据封装的角度来考虑

4、设计时没有什么方法，过程是：a确定外部接口；b从需求中分析出所有的名词；c将这些名词分类；d形成类的层次和框架；e考虑各个类之间的交互，完善接口；

现在看来，还是得从4+1视图的各个方面进行考虑，才能将设计做得更好。