面向对象编程的设计实际上追求的就是：高内聚(Cohesion)和低耦合(Coupling)。其实很多编程范式都是为了达到这个目标，面向对象编程只是其中之一。

在面向对象系统的设计和开发中，我们已经积累了很多的原则，比如面向对象中的封装、继承和多态、面向接口编程、优先使用组合而不是继承、将抽象和实现分离的思想等等。设计模式其实就是这些原则和思想的体现，特别是组合(委托)和继承的差异带来系统在耦合性上的差别，更是在设计模式多次涉及到。

常用模式

Factory

1、定义创建对象的接口，封装对象的创建 2、将实际创建工作延迟到子类中，例如，类A中药使用类B,B是抽象父类，但是在类A中不知道具体要实例化哪一个B的子类，但是在类A的子类D中是可以知道的。在A中无法使用 new B***()方法 3、将创建工作延迟到子类中后，核心工厂类不再负责产品的创建，这样核心类成为一个抽象工厂，只提供工厂子类必须实现的接口，这样的好处是可以不用修改已有的工厂类的情况下增加新的产品（每一种产品，都分别对应相应的工厂子类负责其创建工作）

AbstractFactory

要创建一组相关或者相互依赖的对象

作用：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

  • 总结 工厂模式主要是为创建对象提供过渡接口，以便将创建对象的具体过程屏蔽隔离起来，达到提高灵活性的目的。 工厂模式可以分为三类： 1）简单工厂模式（Simple Factory） 2）工厂方法模式（Factory Method） 3）抽象工厂模式（Abstract Factory） 这三种模式从上到下逐步抽象，并且更具一般性。 GOF在《设计模式》一书中将工厂模式分为两类：工厂方法模式（Factory Method）与抽象工厂模式（Abstract Factory）。将简单工厂模式（Simple Factory）看为工厂方法模式的一种特例，两者归为一类。

区别 工厂方法模式： 一个抽象产品类，可以派生出多个具体产品类。
一个抽象工厂类，可以派生出多个具体工厂类。
每个具体工厂类只能创建一个具体产品类的实例。 抽象工厂模式： 多个抽象产品类，每个抽象产品类可以派生出多个具体产品类。
一个抽象工厂类，可以派生出多个具体工厂类。
每个具体工厂类可以创建多个具体产品类的实例。
区别： 工厂方法模式只有一个抽象产品类，而抽象工厂模式有多个。
工厂方法模式的具体工厂类只能创建一个具体产品类的实例，而抽象工厂模式可以创建多个。 两者皆可。

Singleton单例模式

Singleton 是对全局变量的取代策略 作用：保证一个类只能有一个实例，并提供一个全局唯一的访问点。

仅有一个实例：通过类的静态成员变量来体现。 提供访问它的全局访问点：访问静态成员变量的静态成员函数来体现。

Builder建造者模式

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

Builder模式和AbstractFactory模式在功能上很相似，因为都是用来创建大的复杂的对象，它们的区别是：Builder模式强调的是一步步创建对象，并通过相同的创建过程可以获得不同的结果对象，一般来说Builder模式中对象不是直接返回的。而在AbstractFactory模式中对象是直接返回的，AbstractFactory模式强调的是为创建多个相互依赖的对象提供一个同一的接口。

适用于以下情况:

1)当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。

2)当构造过程必须允许被构造的对象有不同的表示时。 Builder：定义创建对象过程的抽象，提供构建不同组成部分的接口

其中：BuildPartA,BuildPartB,BuildPartC是对一个对象不同部分的构建函数接口,由Builder的派生类ConcreteBuilder1、ConcreteBuilder2来具体实现. 另外还有一个需要注意的函数,就是Director::Construct函数,这个函数里面通过调用上面的接口函数完成对象的构建–也就是说各个不同部分装配的过程都是一致的(同样的调用的Construct函数),但是不同的构建方式会有不同的表示(根据Builder的实际类型来决定如何构建,也就是多态)

Builder模式是基于这样的一个情况:一个对象可能有不同的组成部分,这几个部分的不同的创建对象会有不同的表示,但是各个部分之间装配的方式是一致的.比方说一辆单车,都是由车轮车座等等的构成的(一个对象不同的组成部分),不同的品牌生产出来的也不一样(不同的构建方式).虽然不同的品牌构建出来的单车不同,但是构建的过程还是一样的

也就是说,Director::Construct函数中固定了各个组成部分的装配方式,而具体是装配怎样的组成部分由Builder的派生类实现.

实现: Builder模式的实现基于以下几个面向对象的设计原则:

1)把变化的部分提取出来形成一个基类和对应的接口函数,在这里不会变化的是都会创建PartA和PartB,变化的则是不同的创建方法,于是就抽取出这里的Builder基类和BuildPartA,BuildPartB接口函数

2)采用聚合的方式聚合了会发生变化的基类,就是这里Director聚合了Builder类的指针.

以上，通过两个派生类ConcreteBuilder1、ConcreteBuilder2定义了两种不同的建造细节（建造步骤是一样的，由Construct函数确定），通过两个派生类所建造出来的对象，对外部所展现出来的属性或者功能是不一样的，由各自Builder派生类中的建造方法（BuildPartA、BuildPartB、BuildPartC）决定。

  • 总结 建造者模式和工厂模式非常相似呀，但是记住一点你就可以游刃有余的使用了：

建造者模式最主要功能是基本方法的调用顺序安排，也就是这些基本方法已经实现了；

而工厂方法则重点是创建，你要什么对象我创造一个对象出来，组装顺序则不是他关心的。

建造者模式使用的场景，一是产品类非常的复杂，或者产品类中的调用顺序不同产生了不同的效能，这个时候使用建造者模式是非常合适

Prototype原型模式

作用：

用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。

Prototype模式提供了一个通过已存在对象进行新对象创建的接口（Clone）， Clone()实现和具体的语言相关，在C++中通过拷贝构造函数实现。

Prototype模式和Builder模式、AbstractFactory模式都是通过一个类（对象实例）来专门负责对象的创建工作（工厂对象），它们之间的区别是：Builder模式重在复杂对象的一步步创建（并不直接返回对象），AbstractFactory模式重在产生多个相互依赖类的对象，而Prototype模式重在从自身复制自己创建新类。

理解: Bridge用于将表示和实现解耦,两者可以独立的变化.在Abstraction类中维护一个AbstractionImplement类指针,需要采用不同的实现方式的时候只需要传入不同的AbstractionImplement派生类就可以了.

Bridge的实现方式其实和Builde十分的相近,可以这么说:本质上是一样的,只是封装的东西不一样罢了.两者的实现都有如下的共同点:

抽象出来一个基类,这个基类里面定义了共有的一些行为,形成接口函数(对接口编程而不是对实现编程),这个接口函数在Buildier中是BuildePart函数在Bridge中是Operation函数;

其次,聚合一个基类的指针,如Builder模式中Director类聚合了一个Builder基类的指针,而Brige模式中Abstraction类聚合了一个AbstractionImplement基类的指针(优先采用聚合而不是继承);

而在使用的时候,都把对这个类的使用封装在一个函数中,在Bridge中是封装在Director::Construct函数中,因为装配不同部分的过程是一致的,而在Bridge模式中则是封装在Abstraction::Operation函数中,在这个函数中调用对应的AbstractionImplement::Operation函数.就两个模式而言,Builder封装了不同的生成组成部分的方式,而Bridge封装了不同的实现方式.

桥接模式就将实现与抽象分离开来，使得RefinedAbstraction依赖于抽象的实现，这样实现了依赖倒转原则，而不管左边的抽象如何变化，只要实现方法不变，右边的具体实现就不需要修改，而右边的具体实现方法发生变化，只要接口不变，左边的抽象也不需要修改。

Bridge桥接模式

作用：将抽象部份与它的实现部份分离，使它们都可以独立地变化。

将抽象(Abstraction)与实现(Implementation)分离，使得二者可以独立地变化。

桥接模式号称设计模式中最难理解的模式之一，关键就是这个抽象和实现的分离非常让人奇怪，大部分人刚看到这个定义的时候都会认为实现就是继承自抽象，那怎么可能将他们分离呢。

《大话设计模式》中就Bridge模式的解释：

手机品牌和软件是两个概念，不同的软件可以在不同的手机上，不同的手机可以有相同的软件，两者都具有很大的变动性。如果我们单独以手机品牌或手机软件为基类来进行继承扩展的话，无疑会使类的数目剧增并且耦合性很高，（如果更改品牌或增加软件都会增加很多的变动）两种方式的结构如下：

常用的场景 1.当一个对象有多个变化因素的时候，考虑依赖于抽象的实现，而不是具体的实现。如上面例子中手机品牌有2种变化因素，一个是品牌，一个是功能。

2.当多个变化因素在多个对象间共享时，考虑将这部分变化的部分抽象出来再聚合/合成进来，如上面例子中的通讯录和游戏，其实是可以共享的。

3.当我们考虑一个对象的多个变化因素可以动态变化的时候，考虑使用桥接模式，如上面例子中的手机品牌是变化的，手机的功能也是变化的，所以将他们分离出来，独立的变化。

优点 1.将实现抽离出来，再实现抽象，使得对象的具体实现依赖于抽象，满足了依赖倒转原则。

2.将可以共享的变化部分，抽离出来，减少了代码的重复信息。

3.对象的具体实现可以更加灵活，可以满足多个因素变化的要求。

缺点 1.客户必须知道选择哪一种类型的实现。

设计中有超过一维的变化我们就可以用桥模式。如果只有一维在变化，那么我们用继承就可以圆满的解决问题。

Adapter适配器模式

作用：将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

分为类适配器模式和对象适配器模式。

系统的数据和行为都正确，但接口不符时，我们应该考虑使用适配器，目的是使控制范围之外的一个原有对象与某个接口匹配。适配器模式主要应用于希望复用一些现存的类，但是接口又与复用环境要求不一致的情况。

想使用一个已经存在的类，但如果它的接口，也就是它的方法和你的要求不相同时，就应该考虑用适配器模式。

比如购买的第三方开发组件，该组件接口与我们自己系统的接口不相同，或者由于某种原因无法直接调用该组件，可以考虑适配器。

分类

结构型模式

Bridge（桥接）模式

Adapter（适配）模式

Decorator（装饰）模式

Composite（组合）模式

Flyweight（享元）模式

Facade（外观）模式

行为模式

Template模式