再谈设计模式

关于对象创建：

单利模式 意图：嗯比如管理类什么的

抽象工厂模式 意图：一个复杂对象由很多部分组成，而且组件间还有一定的组合关系，可以使用抽象工厂模式，也就是说，一个具体工厂创建出来的组件一定符合某个具体对象的要求

build模式 意图：一个对象可能由很多复杂对象构成，创建起来很复杂，可以在一个builder中进行条件化创建，和抽象工厂模式的一个重要区别是，抽象工厂模式关注创建零部件，而build模式更关注创建一个实际对象（组装）

prototype原型模式 意图：创建一个对象往往套路太深，我们可以直接用一个已存在的类直接copy过来修改一下一些属性 这里有浅拷贝和深拷贝的问题

flyweight享原模式 意图：太多重复类会造成资源的浪费，cocos中的sprite好像就有池化，总的来说为了性能，为了复用 静态属性池

为了适应：

Iterator模式 意图：很多事情宏观上有相似性（next，hasNext），但实现上往往有细微差别，我们希望在尽可能不修改实现类的情况下访问类元素

适配器Adapter模式 意图：在我们使用第三方库等情况时，他的类的接口可能不符合我们的要求，但功能却符合需求，因此，我们可以用一个接口符合我们要求的类区包装该类（组合），以达到我们的需求

facade 外观模式 意图：当一个库提供了很多方法，尤其是一个第三方的工具库，我们往往需要对其再封装，提供在某些场景下更简单、简洁、实用的api，提供高层api

巧用父子类：

template模板模式 意图：都是套路，很多事物的处理是按步骤的，因此我们可以把步骤抽取出来，更关心实现逻辑，提高效率

decorator装饰器模式 意图：保持相同的接口，但我们希望在具体处理的时候加一些小的修饰，比如在文字前面加点前缀，其他的还是原来的样子，这样就可以用一个新的类继承原来的类，重写要修饰的方法，在前后加上修饰（AOP？？） IOStream

Proxy代理模式 意图：想屏蔽真实对象的信息，或者延迟创建对象（创建对象很费时），当然动态代理在解耦AOP方面有更大的作用 静态代理：主要可以屏蔽真实对象的某些信息，如果在真实对象处理时比较费时，或对象的生成比较费时，可以先在proxy对象处理，到必须真是对象处理时才创建、调用真实的对象。动态代理

一视同仁：

Composite模式 意图：用面向对象OO的思想考虑问题，有时候看似不同的事物，其本质可能是相同的 在linux操作系统下，文件和文件夹以相同的方式处理

分分合合：

Bridge模式 意图：减少实现类，灵活生成具有不同行为的类，比如四种颜色四种粗细的蜡笔则需要十六只蜡笔，而用油画笔则只要四只笔，四种颜色 。 当有多个变量时，分开设计可以减少类的数量

Strategy策略模式 意图：我们可能在面对现实问题时经常需要不同的算法去解决 典型的对于不同需求，替换使用不同的算法

责任分明：

chain模式 pipline 意图： 单一责任，每个类我们希望他们保持单一的责任，同时强调了数据流和数据的过滤

Command模式 意图：也是为了尽可能的分离各自的职责 在游戏设计中比较多，将具体的执行命令封装到类中，执行时传入被执行对象，执行由具体命令类执行

处理关系：

mediator仲裁者模式 意图：我们希望每个组件只关心自己的事，不用担心自己变化后相关组件应该如何变化，因此可以把改变通知给mediator仲裁者，有仲裁者统一改变组件的状态 对于一些组件之间有复杂关系，可以设置一个仲裁者，在某个组件发生状态改变的时候，通知仲裁者，仲裁者在根据他们的状态修改其他组件的状态，典型的，一个checkbox的禁用可能导致一组输入组件的禁用

Observer模式 意图：与制裁者类似这里状态改变后发出通知给Observer，当某个Observer关心某类事件或状态改变时，只要订阅相关事件即可，最大程度的解耦了“逻辑”与s“视图”之间的联系 观察者模式 RXJava Observer和Subscriber是等同的 Subscriber实现了Observer，Observable被观察者，要subscribe到一个Observer

处理状态：

memnto备忘录模式 意图：我们希望将来有可能恢复或查看某对象的某些状态（状态敏感） 备忘录模式 设置一个备忘录类Memento，当某个对象状态发生改变的时候，创建保存一个memento，undo就是恢复到上一个memento，reset就是设置为最开始的memento

state模式，对if else下的几种状态，用类来表示，然后在类中分别处理事件

Interpreter模式 意图：不想说 自己创造一门语言

visitor模式 不想说