只节选了几个讲。。结果老师讲太快 把明天的内容也讲了 囧 于是明天改成Lua 也。。。

结构型的例子是以下：

• 适配器（Adapter）：某游戏开发团队设计游戏的时候物理模块没有时间设计，于是向外面的公司购买了一个物理模块，但是两个接口不合 于是这里就用到了适配器。
  扩充一下，类适配器和对象适配器：
  • 类适配器：使用继承实现（在Java里没有多继承，囧，都没有细考量过），在使用时直接使用适配器类即可。
  • 对象适配器：优先使用组合而并非继承，耦合度低，而且即使传入子类对象也可以适配，在使用时需要一个适配器类和一个被适配的对象。
     
• 装饰者（Decorator）：有些物体并不适用于普通的物理引擎。比如默认物体遇到墙会反弹，而子弹则应该会自由落体（？），幽灵则会穿透。不改变接口而增加新职责 即装饰者模式了。。
   
• 门面（外观/Facade）：游戏中有许多模块：聊天、交易、任务、角色信息、宠物……UI程序员需要了解所有模块的接口，接口管理不易，且违背了迪米特法则，因此将UI用到的接口都放到一个类中，方便UI程序员调用。
   
• 代理（Proxy）：游戏玩家越来越多，原本放在游戏服务器上的数据库需要独立一台服务器，如果修改原来的数据库相关操作需要大量修改（？不是只改一下url么？？？），此时使用Proxy模式，游戏调用Proxy类，不关心Proxy是如何实现访问数据库的，而在Proxy里面具体实现。

行为型模式例子：

• 责任链（Chain of Responsibility）：策划提出进入某一个岛需要判断是否持有某物品、是否有特殊技能、角色等级、生命值……而这些条件是不一定的，需求可能随时变动。责任链模式很动态 = =
  顺便说一下纯的责任链模式和不纯的责任链模式：
  
  • 纯的责任链模式：对于一个链结点，要吗承担责任，要吗传递到下一个链，这个应用貌似很少见。
  • 不纯的责任链模式：一个链结点可以承担部分责任，比如本例中每个判定都可以在为假的时候丢回去（履行了一部分职责），真的时候才继续往下传。
     
• 观察者（Observer）：许多装备会有特殊效果，比如攻击时有一定几率加成、被攻击时一定几率miss、每次攻击必多伤害一定血值等。这是一对多的关系（如果是一对一 我们可以用策略模式），因此我们将这些事件（攻击、被攻击等）分别设计为主题类，在装备上特殊装备时特殊效果注册对应的主题，于是事件触发时会通知各个特效执行，在装备卸下时就可以注销主题了。
   
• 策略（Strategy）：怪物们都有自己的AI，而且即使同一类的怪物拥有的AI都可能不一样，我们将AI设计成一组策略类，让怪物类组合一个AI对象，需要切换的时候重新设置AI对象即可。

总觉得有些例子还是很牵强。。。 = =||

• 相关文章