设计模式不适合在游戏中应用

设计模式的一个原则是ocp原则，即对改变关闭，对扩展放开。通俗一点的说是，我们可以用设计模式来扩展新的衍生出来的逻辑，但不支持对已有的逻辑的修改。但目前游戏行业的变化太快，与一般的传统行业区别是比较大的，传统行业可能是某一个业务模块已经成型，不需要我们日后再去频繁的修改。但游戏开发来说，可能某个游戏策划，对游戏的规划一开始并不是很清楚（我得承认国内大不部分游戏公司的策划是这样的），一开始设计出来的系统，在开发工作还没有完工的时间，或者说开发工作刚刚完成了，这时游戏设计者对这个系统的流程或者功能又有新的想法。而这个新的设计基本上要或多或少甚至彻底改变已完成的功能。这时的系统的要改变已有的功能模块，这对设计模式的原则是矛盾的（对扩展开放，对更改关闭）。而这个系统中你用的设计模式将是你的负担。因为你在这个系统上的抽象的东西越多，你的抽象代码将会增多，而要彻底修改这个逻辑的时间，这些抽象出来的代码将成为你的负担。

个人认为在游戏开发中，我们先不要去想抽象的多么高层，请忘记这句“抽象的越高你的代码的可读性越好，越能适应系统的变更”，在游戏开发中我们需要的是快速，可靠，稳定的开发方式。传统的分模块开发，我认为我们在游戏开发中可以充分的利用。每个模块尽量做到高度独立，模块跟外面的通信方式进可能的做到统一。小的模块组合在一起成为一个组件，几个组件组合成一个小的系统。这样，如果我们在游戏开发中，遇到不是较大的变化时间，尽可能找到某个模块或者某几个模块，来做修改。如果游戏系统某个流程有了个根本性的变化的时间，我们可以直接把变化大的模块拿出去，重新的一个新的模块来替代原有的变化了的模块。另外如果游戏系统出现了较大的BUG，或者宕机之类的问题如果一时找不到问题的所在，而这个模块又比较复杂的话，我们尽可以直接，把这个模块删除，重新写一个新模块来代替，而这样不会影响到其他的模块。