oop设计模式抽象总结

创建型模式：

一、简单工厂，工厂方法，抽象工厂

简单工厂：只有一层抽象，由工厂去获得抽象类的具体对象，工厂内的方法可以看做静态方法

工厂方法：有两个抽象，工厂的抽象和具体类的抽象。

举个例子：有个汽车生产工厂，最开始规模比较小，轿车和SUV啊客车等在一个车间里面，你要哪个车就对这个工厂说，我要xx车，这个工厂就出来一个这个车。

一段时间的运行效益越来越好，要把这三条流水线分开，就分出了三个工厂，轿车工厂，SUV工厂和客车工厂。

工厂方法和简单工厂相比，1工厂方法更好的实现了开闭原则，要增加类只需要增加代码，简单工厂会改类里面的代码，会增加分支判断2工厂方法把简单工厂的if else分支判断交给了客户端

抽象工厂：拿数据库的例子来说，有user表操作接口（包括SQL实现，和access实现）有dept表操作接口（包括SQL实现和access实现）抽象工厂类（获取user表操作，获取dept表操作）具体实现类（SQL工厂access工厂）。抽象工厂的客户端需要知道有哪些工厂可以选择，先new出来具体的工厂，再用具体的工厂获取具体的对象。

抽象工厂这个例子里面有两种具体的表（user和dept），两个处理方式（SQL和access）。按处理方式来分成两种工厂，每个工厂都有两种抽象的表处理，每个表处理是一种抽象。

二、单例模式

单例模式的特点是有两个类（一个业务类构造方法私有，一个工厂类负责保存业务类的单例，注意多线程的使用）

三、建造者模式

建造过程分为几部分，由Builder决定

具体的创建部分，由具体的类Dress决定

创建部分的先后顺序，由Director决定

建造者模式可以将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

四、原型模式

结构型设计模式

适配器模式、桥接模式、装饰模式、组合模式、享元模式、代理模式、外观模式

死亡之组啊、。

适配器模式：

桥接模式：

品牌和软件可以独立变化，增加

装饰模式：

组合模式：

享元模式：

程序设计中，有时需要生成大量细粒度的类实例来表示数据，如果能发现这些实例除了几个参数外基本都是相同的，如果能把那些参数移到类实例外面，在方法调用时将它们传进来，就可以通过共享大幅度减少单个实例的数目User变化的 website不变的

什么情况用享元模式：
如果一个应用程序使用了大量的对象，而大量的这些对象造成了很大的存储开销时就应该考虑使用；还有就是对象的大多数状态是外部状态如果删除对象的外部状态，可以用相对较少的共享对象取代很多组对象，也可以考虑用享元模式

代理模式：

应用场景一：远程代理，为一个对象在不同的地址空间提供局部代表。这样可以隐藏一个对象存在于不同地址空间的事实
应用场景二：虚拟代理，是根据需要创建开销很大的对象。通过它来存放实例化需要很长时间的真实对象。例如很大的HTML网页，图片框通过虚拟代理替代了真实的图片
应用场景三：安全代理，用来控制真实对象访问时的权限。一般用于对象应该有不同的访问权限的时候。
应用场景四：智能指引，是指当调用真实的对象时，代理处理另外一些事。如计算真实对象引用次数，访问一个世纪对象时，检查是否已经锁定它，确保其他对象不能改变它。都是通过代理在访问一个对象时附加一些内务处理

外观模式：

行为型设计模式一：

观察者模式、模板方法模式、命令模式、状态模式、职责链模式

观察者模式：

观察者模式又叫发布-订阅模式
观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。
这个主题对象在状态发生变化时，会通知所有观察者对象，使他们能够自动更新自己

模板方法模式：

当要完成在某一细节层次一致的一个过程或一系列步骤，
但其个别步骤在更详细层次上的实现可能不同时，我们通常考虑用模板方法模式来处理

当不变的和可变的行为在方法的子类实现中混合在一起的时候，不变的行为就会在子类中重复出现。我们通过模板方法模式把这些行为搬移到单一的地方
这样就帮助子类摆脱重复的不变行为的纠缠

命令模式：

命令模式好处；把请求一个操作的对象与知道怎么执行一个操作的对象分割开
1较容易设计一个命令队列
2在需要的情况下，较容易将命令记入日志
3允许接收请求一方是否要否决请求
4容易实现请求的撤销和重做
5加新的命令类很容易

状态模式：简单版

复杂版，上班的状态。

职责链模式：

行为型设计模式二组：

解释器模式、中介者模式、访问者模式、策略模式、备忘录模式、迭代器模式

解释器模式：

如果要增加一个音速
直接增加一个Speed类，然后在客户端条件判断里面加一个分支
可以用简单工厂加反射这样可以不用增加客户端代码了。

中介者模式：

中介者与同事类要互相关联
中介者模式很容易在系统中应用，也很容易在系统中误用，当系统中出现了‘多对多’交互复杂的对象群时，不要急于使用中介者模式，
而要先反思你的系统在设计上是否合理
中介者模式优点：
mediater的出现减少了各个Colleague的耦合，使得可以独立改变和复用各个Colleague类和mediater
其次由于把对象如何协作进行了抽象，将中介作为一个独立的概念并将其封装在一个对象中，这样关注的对象就从对象各自本身的行为转移到它们之间的交互上来
也就是站在一个更宏观的角度看待系统
中介者模式缺点：
由于ConcreteMediater控制了集中化，于是就把交互复杂性变为了中介者的复杂性，这样就使得中介者会变得比任何一个ConcreteColleague都复杂。

应用场景：中介者模式一般应用于一组对象以定义良好但是复杂的方式进行通信的场合以及想定制一个分布在多个类中的行为，而又不想生成太多的子类的场合

访问者模式：

这样如果要增加结婚状态就很方便了
男女对比这么多的原因是因为人类在性别上就只有男人和女人两类，这也正是访问者模式可以实施的前提
（保证了Action类中的方法数量稳定）
访问者模式适用于数据结构相对稳定的系统，它把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作集合可以相对自由地演化
访问者模式的目的是要把处理从数据结构分离出来，很多系统可以按照算法和数据结构分开，如果这样的系统有比较稳定的数据结构，又有易于
变化的算法的话，使用访问者模式就是比较合适的，因为访问者模式使得算法操作的增加变得容易
反之，如果这样的系统数据结构对象易于变化，经常要有新的数据对象增加进来，就不适合使用访问者模式

优点：增加新的操作很容易，因为增加新的操作就意味着增加一个新的访问者，访问者模式将有关的行为集中到一个访问者对象中
缺点：使增加新的数据结构变得困难

策略模式：