回顾游戏中的设计模式：策略模式vs抽象工厂

最近有时间看看设计模式方面的书，好多东西时间久了不看就变得生疏起来， 在这里会抽出时间把自己在工作中使用过的设计模式做下总结。

刚才在看到别人说，简单工厂模式是“通过提供单独的一个类，来实现创建实例对象的过程”，可以使用反射来替换掉程序中的switch/if..else，嗯，这是没问题的，但实际应用中，在移动端还要尽量少的去频繁使用反射Reflection，严重依赖字符串的功能都会存在效率的问题。

今天在看到策略模式（Strategy Pattern)的时候，突然间意识到自己在16年的一个项目中，有一处应用不够合理。

当时在存储游戏数据部分，我是通过直接将对象图转化成字节流的形式，即序列化。

那么序列化有多种方式，你可以序列化成XML，也可以是二进制，或者是SOAP（类似于XML，不建议使用，只是为了多提供一个策略演示)。

那么这时候，采用哪种设计模式？

当时使用的是抽象工厂，但实际上，他更符合策略模式。即我们将多个“策略”抽象成接口的形式来解耦合。

比如说我要回大连，我可以坐火车，飞机，客车，或是自驾。我最终的目的是相同的，只是到达目的的方式不同。

然而在代码上，策略模式和抽象工厂区别不是很大，后来我搜索了一下关于两个设计模式之间的区别，找到了一个非常好的解释 。

2009年的一个帖子。解释如下：

抽象工厂属于创建型的，而策略模式属于行为型。

抽象工厂往往是抽取的同一基类(Class)的不同子类。

策略模式往往抽取的是同一接口的不同实现。

那么显然，我在序列化的时候，我序列化为哪种格式，只是行为不同（纯行为上），结果相同，而且也符合同一接口的不同实现。

那么说到这里了，就把之间的代码给修改一下，修改为策略模式。

定义序列化接口：

ISerializable.cs
 

声明了两个方法，序列化和反序列化。

下面实现具体的序列化类，买二手游戏平台分别是Binary,XML,SOAP

BinarySerialized.cs

XMLSerialized .cs
 

SOAPSerialized.cs(SOAP要引入dll[System.Runtime.Serialization.Formatters.Soap.dll])
 

最后我们定义一个序列化的上下文，面向接口编程：

SerializableContext.cs
 

演示代码：
 

在这里定义了一个DataManager类，DataManager包含了
 

两个字段，并进行初始化，然后对DataManager类，进行序列化和反序列化测试。