开发者社区
上篇文章介绍了外观模式，在外界管理各个子系统时，使用外观模式减少与内部多个子系统模块进行交互，从而降低应用程序的复杂度。本文就介绍另外一种设计模式，中介者模式（又称调停者模式）。当我们的多个系统模块之间会有通信，如果系统之间杂乱无章的进行通信数据交互的话，耦合性很高，不容易维护。中介者模式就是解决这种情况，定义一个中介对象来封装系列对象之间的交互。中介者使各个对象不需要显示的相互应用，从而降低其耦
上篇文章介绍了设计模式中的单例模式与状态模式，接着后面的设计模式介绍，本篇文章和大家介绍外观模式。在游戏中一个场景可能需要与多个系统进行信息交互，比如战斗系统，背包系统，经济系统等，在编写代码时候势必要将各个系统之间的通信和依赖降低到尽可能的小。这时候使用外观模式最适合，将应用程序只能看到外观（facade）对象，不需要关注内部的细节对象，从而降低应用程序的复杂度，提高应用程序的可维护性。案例分析
使用设计模式来提高程序库的重复利用性是大型程序项目开发必须的。但是在“四人帮”的设计模式概述中提到了23种标准设计模式，不但难以记住，而且有些设计模式更多的适用于应用程序开发，对游戏项目引擎设计并没有很多的利用价值。根据经验，精挑细选后，笃志在这里记录一些自认为有利用价值的设计模式，以便之后自己设计时使用。 一、观察者Observer 观察者的设计意图和作用是： 它将对象与对象之间创建一种依赖关系，当其中一个对象发生变化时，它会将这个变化通知给与其创建关系的对象中，实现自动化的通知更新。 游戏中
1.应用场景Cocos2d-x里面有一个非常明显的地方使用了外观模式，它就是SimpleAudioEngine。因为它为CocosDenshion这个子系统的一组接口提供了一个一致的界面，同时定义了一个高层接口，方便客户使用该子系统。对于大多数用户来讲，游戏中操作声音，无非就是播放背景音乐和音效。CocosDenshion这个子系统封装了OpenAL，屏蔽了OpenAL操作声音的低级API。它提供了CDSoundEngine、CDAudioManager两个类来操作和管理声音。具体这两个类是如何工作的这里就
