1.命令模式
比如游戏中的剧情系统，设计不同的命令供策划同事调用。很容易就能增加新的命令类，不影响其它命令。可以排序执行，方便撤消，做日志等。缺点就是命令因为要拆分干净，所以类显得很多。
2.模板方法模式
公会战系统不同状态的子界面。可以在基类中按顺序执行某些方法，就像约定步骤一样，然后在子类中有不同的实现。
3.装饰模式－增强
装饰模式一般在下列情况使用：需要扩展一个类的功能或者给你个类增加附加责任；需要动态的给一个对象增加功能，这些功能可以再动态的撤销；需要增加有一些基本功能的排列组合而产生非常大量的功能，从而使得继承关系变得不现实。
在我们的游戏当中，如果基类中某个属性值有不同类型，通常都是增加一个int值，然后对应不同的枚举类型。这样有个问题就是每次新增加一个属性，都要去修改基类。并且随着这些属性越来越多，基类会变得非常复杂。这样使用者就得小心操控每个属性值，比如角色基类，玩家A会选择战士+红色头发+白色上衣+蓝色裤子+……，玩家B会选择术士+蓝色头发+白色上衣+黄色裤子……。使用继承是必然的选择了，简单的继承是把上述属性拆分到几个二级类中，避免一级基类属性多到爆炸。当然还有一种拆分就是全拆干净了，把每个属性对应的枚举类型都扩展出一个二级类。用的时候再自己去组合这些二级类，这就是装饰模式。对于设计者而言，只要把所有属性对应的二级类写出就足够应付任何场面了。对于使用者，不管千变万化，总是可以装饰出来想要的目标，并且仍然还是基类的类型，是不是很像穿衣服，一件一件随便穿，最终还是那个人。装饰模式关键有两点：一是自己本身就扩展自基类，这样不管装饰多少遍，它还是那个基类。二是构造函数里参数传入的也是基类的类型，这样可以满足多重装饰。装饰模式以对客户透明的方式动态地给一个对象附加上更多的责任。另外一个例子就是咖啡店添加不同材料组成的咖啡，去算价格的问题。加牛奶，加糖，加奶油，加各种东西，对应了无数种组合。并且还有某种材料要加双份。对于代码设计者而言，是不可能为每一种组合都设计好计算价格的算法。只能实际使用时去计算，这时装饰模式就可以解决问题，由使用者组装。具体参考 设计模式（九）装饰模式（Decorator）
4.适配器模式－兼容
适配器模式在系统升级的时候使用的频率很高，对旧系统的一些功能方法在新系统中引用。
过多的使用适配器，会让系统非常零乱，不易整体进行把握。比如，明明看到调用的是A接口，其实内部被适配成了B接口的实现，一个系统如果太多出现这种情况，无异于一场灾难。因此如果不是很有必要，可以不使用适配器，而是直接对系统进行重构。
5.代理模式－隔离
代理模式给某一个对象提供一个代理对象，并由代理对象控制对原对象的引用。
常见权限控制隔离
6.责任链模式
经常举的例子就是一个苦逼底层打了份申请，然后向上级层层申请批准。事件机制里很常见，比如Android触摸事件
7.状态模式
对象不同状态都会设计成一个类，并且在里面写好能进入哪个状态。责任链则会把能进哪个交给使用者去决定。
8.中介模式
网状的交叉关系，变成一对多的关系，比如联合国
9.建造者模式
会有一个Director来控制建造流程，实际创建交给xxBuilder，而xxBuilder是可以随时替换的
10.组合模式
就像WINDOWS的资源管理器一样，树结构中的根和叶子，可以统一对待
11.桥接模式
当对象的关系出现两个维度同时变化时，就需要4个类。桥接就是让两个类各自做变化，由使用者来决定具体的4个变化。
12.享元模式
和对象池一样希望能复用对象，不过对象池里一般都是相同的对象，享元里面是不一样的
设计模式个人感受
最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
- 文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
- 文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
- 文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
推荐阅读更多精彩内容
- Android 自定义View的各种姿势1 Activity的显示之ViewRootImpl详解 Activity...
- 导师/录人 整理/巴山雨 2.如何做到有质量地输出？【小众圈子写作圈第2期】录人老师小说写作课笔记整理7.17（下...
