RFID会议签到系统总结（二十二）――系统中的模式

 

该总结的东西都总结得差不多了，剩下的都是一些细枝末节的了，基本可以收尾了，这一篇讲一讲设计模式。

设计模式是个什么东西，它其实只是前人在当前系统实现基本手段基础上提取出来的一些方法论，目的是为了更好更快的解决我们在系统实现中碰到的各种问题。其实如果总是处于那种“你来我往”的状态之中，没有静下心来细细的思量，无法把握到项目的全貌，没有精益求精的态度，那些方法论不用也罢。可幸这一次上述的如果都没有，所以才能一直写这个系统的总结写了二十来篇，可谓收获颇丰。

 

一、创建型模式

创建型模式里用得比较多，也比较好掌握的就是Singleton模式了，这个模式对于实现者的设计能力要求不甚高，这也是我最早运用的模式之一。在此次系统实现中当然也不会少，不过其中由于环境特性，我有些实现的地方并没有用标准的方法，而是简化了。那些地方可以说徒有其名而无其实，但最终的效果还是一样的。

Factory与Abstract Factory模式是比较耳熟能详的二个模式，其二者很容易混淆起来，其实我在运用它们的时候也不是非常的得心应手，总的来说实现了一种设计后并不能严格意义上区分它是哪一个模式。对于很多的模式都有这种感觉，特别是当一个设计开始趋向有层次的复杂之后，这从另一方面印证了设计模式是一种特定条件下的方法论的观点。

在这一次的系统中并没有很多的、很复杂的类的创建，所以Prototype与Builder模式也无从谈起。系统中类的创建要化点脑筋的就数硬件访问与服务加载了，二者实现手段是一致的。都是先提取一个公共的接口，系统启动创建时，根据配置文件创建相关类，并设置相关属性，最后把创建出来的类放入到一个集合中供系统调用。这里有Abstract Factory，也有Bridge以及Iterator。

 

二、结构型模式

Adapter在这新的系统用处不大，但Bridge则大有用武之地。特定硬件与系统的解耦就是通过Bridge来实现的，还记得硬件访问时提取出来的那个接口吗？那个接口与我们封装过的特定硬件访问类之间就是桥的关系。

硬件技术总归是一种比较复杂的东西，我们的系统利用的只是它们功能的小部分，同时厂商提供的硬件访问API对于系统是很不友好的，它对于我们暴露了过多的细节，这时Facade模式就派上用场了。所以硬件访问这一块是在Facade基础上的Bridge。

其实数据通讯这一块跟硬件访问有异曲同工之妙，通讯组件的逻辑封装与技术封装之间可以认为有Bridge，即不同的通讯技术对于客户端的最终调用是不透明的；而技术封装本身就是一个Facade。

Composite模式最通常的应用就是菜单类了。而Decorator模式在我看来是无处不在，这个模式是“优先使用对象组合，而不用类继承”的典型体现。我说这个模式无处不在并不是说系统中大量充斥着一个个的Decorator，而是说明对象组合的普遍性。最能体现Decorator的价值的地方是数据对象的查询条件、排序设置，数据对象EntityBase与查询条件WhereCondition之间是Decorator关系，而WhereCondition内部则是Composite关系。

Flyweight与Proxy在系统中没有很明显的应用。

 

三、行为型模式

相比前二类模式，行为型模式似乎比较的深奥一点，以前有几次出去面试时，居然不止一次的发现有些人不了解其中的一些模式。抛开一些个体的因素不谈，个人认为行为模式显得“深奥”正是反应了我们真实世界的多变复杂性。我们的世界是如此的难以琢磨，而行为型模式对于这个世界相比前二类模式有更深的介入，以至于我们在运用这一类的模式时有时会很不好权衡利弊。

Command模式，每次提到时好象都拿菜单与工具栏说事，这个运用也是比较的普遍，这一次实现系统当然也就没有放过它。

Iterator模式在行为型模式中算是比较“大众化”的一个模式了，因为集合的运用对于每一个系统实现者来说都是非常必要的，而现在绝大多数的系统框架在集合类的实现上都体现了这个模式的精髓。而Observer是另一个系统框架涉及比较多的模式，事件-委托机制就可以认为是这个模式一种表现。集合与事件是在系统设计与实现中大量运用的，上述二种模式当然就逃不过。

State模式在这次的系统实现的运用中不是非常的到位，因为虽然窗体状态看起来也挺多，但对于界面变化来讲只分为浏览与非浏览二种，而各个状态的操作只有一个“确定”是各异的。State模式在这个场景显得有点鸡肋。

Strategy本来是没什么机会用的，不过在管控端有一个功能，就是显示座位，座位号的排列并不是每次都是从左到右来的，这里有个排座策略问题，这个模式恰好排上用场。

Template Method是行为模式中在我看来运用得很频繁的一个模式，这次系统实现中也大量的运用，比如在单数据窗体中工具栏按钮事件中的一串方法，还有在数据访问对象中的很多方法。其实象这种由父类放一个钩子出去，然后子类Override相关方法实现具体操作的用法，在很久以前还不知道设计模式这个东西的时候就在使用了。

剩下的其他行为型模式有些有太特殊的应用场景(如Interpret)，而有些虽然可以应用到系统中，但鉴于系统需求没有那么深入，犯不着为了一个设计模式复杂化整个系统(如Memento)。

 

最后数了一下，在这次系统实现中共用了12个模式，占了Gof设计模式的一半强，可以说“麻雀虽小，五脏俱全”。半年来的经历比之过去几年的收获还大，当然没有之前的积累也一下子用不上这么多的设计模式，总之过去的那半年虽然没有投身到新技术的大潮中，但还是很值得。