代码说明
l 可以看到，原先的接口中，启动游戏场景只需要一个参数，就是游戏场景名，而进入新的玩家需要提供玩家ID（新游戏都使用玩家ID而不使用玩家账户名）。
l IGame接口就是适配器模式中的目标角色，这是客户所期待的接口。也是针对老的游戏程序所遵循的接口。
l Lobby类相当于调用方或者客户，它原先的代码可能是如下的：
但是由于接口的改变，现在不能直接实例化游戏类，只能实例化适配器类型。虽然还是需要改动，但是这个改动是很小的，而且完全可以通过用动态加载程序集来消除这种改动。
l GameAdapter类是适配器角色，它是适配器模式的核心，用于把源接口转变为目标接口。在这里，我们看到，它实现目标接口。
l Game类型是源角色，或者说是需要适配的对象。或许它也遵循了另外一套接口，不过我们不是很关心这个，因此代码中也没有体现。
l 使用了适配器模式后，客户端代码没有做什么修改。客户端代码老老实实的依赖接口，它并没有错，如果因此依赖对象的修改而需要大幅度修改就很无辜了，我们在适配器中把本来没有关联的两个接口适配在了一起。我们可以看到，适配器做的不仅仅是换一换方法名，如果源角色和目标角色的差异非常大，那么适配器需要做很多工作。
何时采用
l 从代码角度来说， 如果需要调用的类所遵循的接口并不符合系统的要求或者说并不是客户所期望的，那么可以考虑使用适配器。
l 从应用角度来说， 如果因为产品迁移、合作模块的变动，导致双方一致的接口产生了不一致，或者是希望在两个关联不大的类型之间建立一种关系的情况下可以考虑适配器模式。
实现要点
l 适配器模式是否能成功运用的关键在于代码本身是否是基于接口编程的，如果不是的话，那么适配器无能为力。
l 适配器模式的实现很简单，基本的思想就是适配器一定是遵循目标接口的。
l 适配器模式的变化比较多，可以通过继承和组合方式进行适配，适配器可以是一组适配器产品，适配器也可以是抽象类型。
l 适配器模式和Facade的区别是，前者是遵循接口的，后者可以是不遵循接口的，比较灵活。
l 适配器模式和Proxy的区别是，前者是为对象提供不同的接口，或者为对象提供相同接口，并且前者有一点后补的味道，后者是在设计时就会运用的。
