1. 单例模式
确保某一个对象只有一个实例，而且自行实例化并向整个程序提供这个实例。
优点
- 由于单例模式在内存中只有一个实例，减少了内存开支，特别是一个对象需要频繁地创建、销毁时，而且创建或销毁时性能又无法优化，单例模式的优势就非常明显。
- 减少了系统的性能开销，当一个对象的产生需要比较多的资源时，如读取配置、产生其他依赖对象时，则可以通过在应用启动时直接产生一个单例对象，然后永久驻留内存的方式来解决。
- 避免对资源的多重占用。如避免对同一个资源文件的同时写操作。
- 单例模式可以在系统设置全局的访问点，优化和共享资源访问。
缺点
- 单例模式一般没有接口，扩展困难。
- 不利于测试。
使用场景
- 要求生成唯一序列号的环境。
- 在整个项目中需要一个共享访问点或共享数据。
- 创建一个对象需要消耗的资源过多，如要访问IO和数据库等资源。
- 需要定义大量的静态常量和静态方法的环境。
实现
懒汉实现方法，即实例化在对象首次被访问时进行。可以使用类的私有静态指针变量指向类的唯一实例，并用一个公有的静态方法获取该实例。同时需将默认构造函数声明为private，防止用户调用默认构造函数创建对象。
class CSingleton
{
private:
CSingleton(){};
static CSingleton* m_pInstance;
public:
static CSingleton* GetInstance(){
if (m_Instance == NULL )
{
Lock();
if (m_Instance == NULL )
{
m_Instance = new Singleton ();
}
UnLock();
}
return m_pInstance;
}
};
此处进行了两次m_Instance == NULL的判断，是借鉴了Java的单例模式实现时，使用的所谓的“双检锁”机制。因为进行一次加锁和解锁是需要付出对应的代价的，而进行两次判断，就可以避免多次加锁与解锁操作，同时也保证了线程安全。
上面的实现存在一个问题，就是没有提供删除对象的方法。一个妥善的方法是让这个类自己知道在合适的时候把自己删除，或者说把删除自己的操作挂在操作系统中的某个合适的点上，使其在恰当的时候被自动执行。
我们知道，程序在结束的时候，系统会自动析构所有的全局变量。事实上，系统也会析构所有的类的静态成员变量，就像这些静态成员也是全局变量一样。利用这个特征，我们可以在单例类中定义一个这样的静态成员变量，而它的唯一工作就是在析构函数中删除单例类的实例。如下面的代码中的CGarbo类（Garbo意为垃圾工人）：
class CSingleton
{
private:
CSingleton(){};
static CSingleton* m_pInstance;
class CGarbo
{
public:
~CGarbo(){
if(CSingleton::m_pInstance != NULL)
delete CSingleton::m_pInstance;
}
};
static CGarbo garbo;
public:
static CSingleton* GetInstance(){
if (m_Instance == NULL )
{
Lock();
if (m_Instance == NULL )
{
m_Instance = new Singleton ();
}
UnLock();
}
return m_pInstance;
}
};
类CGarbo被定义为CSingleton的私有内嵌类，以防该类被在其他地方滥用。程序运行结束时，系统会调用CSingleton的静态成员Garbo的析构函数，该析构函数会删除单例的唯一实例。
饿汉实现方法：在程序开始时就自行创建实例。如果说懒汉式是“时间换空间”，那么饿汉式就是“空间换时间”，因为一开始就创建了实例，所以每次用到的之后直接返回就好了。
class CSingleton
{
private:
CSingleton(){};
static CSingleton* m_pInstance;
class CGarbo
{
public:
~CGarbo(){
if(CSingleton::m_pInstance != NULL)
delete CSingleton::m_pInstance;
}
};
static CGarbo garbo;
public:
static CSingleton* GetInstance(){
return m_pInstance;
}
};
CSingleton *CSingleton::m_pInstance = new CSingleton();
2. 工厂方法模式
介绍
意图：定义一个创建对象的接口，让其子类自己决定实例化哪一个产品类，工厂模式使其创建过程延迟到子类进行。
主要解决：主要解决接口选择的问题。
何时使用：我们明确地计划不同条件下创建不同实例时。
如何解决：让其子类实现工厂接口，返回的也是一个抽象的产品。
应用实例：
- 您需要一辆汽车，可以直接从工厂里面提货，而不用去管这辆汽车是怎么做出来的，以及这个汽车里面的具体实现。
- Hibernate 换数据库只需换方言和驱动就可以。
优点：
- 一个调用者想创建一个对象，只要知道其名称就可以了。
- 扩展性高，如果想增加一个产品，只要扩展一个工厂类就可以。
- 屏蔽产品的具体实现，调用者只关心产品的接口。
缺点：
每次增加一个产品时，都需要增加一个具体类和对象实现工厂，使得系统中类的个数成倍增加，在一定程度上增加了系统的复杂度，同时也增加了系统具体类的依赖。这并不是什么好事。
**使用场景： **
- 日志记录器：记录可能记录到本地硬盘、系统事件、远程服务器等，用户可以选择记录日志到什么地方。
- 数据库访问，当用户不知道最后系统采用哪一类数据库，以及数据库可能有变化时。
- 设计一个连接服务器的框架，需要三个协议，"POP3"、"IMAP"、"HTTP"，可以把这三个作为产品类，共同实现一个接口。
注意事项：
作为一种创建类模式，在任何需要生成复杂对象的地方，都可以使用工厂方法模式。有一点需要注意的地方就是复杂对象适合使用工厂模式，而简单对象，特别是只需要通过 new 就可以完成创建的对象，无需使用工厂模式。如果使用工厂模式，就需要引入一个工厂类，会增加系统的复杂度。
工厂方法模式：定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。
实现
简单工厂模式
#include <iostream>
using namespace std;
class Shape
{
public:
virtual void draw()=0;
};
class Square : public Shape
{
public:
void draw(){
cout<<"This is a square."<<endl;
}
};
class Rectangle : public Shape
{
public:
void draw(){
cout<<"This is a rectangle."<<endl;
}
};
class Circle :public Shape
{
public:
void draw(){
cout<<"This is a circle"<<endl;
}
};
class SimpleFactory
{
public:
typedef enum ShapeType
{
ShapeSquare,
ShapeRectangle,
ShapeCircle
}SHAPETYPE;
Shape* CreateShape(SHAPETYPE type)
{
switch(type)
{
case ShapeSquare:
return new Square();
case ShapeRectangle:
return new Rectangle();
case ShapeCircle:
return new Circle();
default:
return NULL;
}
}
};
int _tmain(int argc, _TCHAR* argv[])
{
SimpleFactory* myFactory = new SimpleFactory();
Shape* myShape = myFactory->CreateShape(SimpleFactory::ShapeCircle);
myShape->draw();
delete myShape;
myShape = NULL;
delete myFactory;
}
上述实现需要手动释放申请在堆上的内存，可以利用智能指针实现自动释放。
工厂方法模式
拥有几个工厂，都派生自同一抽象工厂类，可以生产不同的产品。
C++设计模式——工厂方法模式
class AbstractProduct
{
public:
virtual void operation()=0;
};
class ProductA : public AbstractProduct
{
public:
virtual void operation(){
cout<<"This is A!"<<endl;
}
};
class ProductB : public AbstractProduct
{
public:
virtual void operation(){
cout<<"This is B!"<<endl;
}
};
class AbstractFactory
{
public:
virtual AbstractProduct* createProduct()=0;
};
class FactoryA : public AbstractFactory
{
public:
AbstractProduct* createProduct(){
return new ProductA();
}
};
class FactoryB : public AbstractFactory
{
public:
AbstractProduct* createProduct(){
return new ProductB();
}
};
int main()
{
AbstractFactory* myFactory = new FactoryA();
AbstractProduct* myProduct = myFactory->createProduct();
myProduct->operation();
delete myProduct;
myProduct = NULL;
delete myFactory;
myFactory = NULL;
}
注意：在上述两个实现中，为简单起见，并没有定义构造函数和虚构函数。其中，基类的虚构函数应为虚函数，这样才能保证，delete操作能够调用合适的析构函数。
抽象工厂模式
拥有几个抽象工厂类。
3. 建造者模式
将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
介绍
主要解决在软件系统中，有时候面临着"一个复杂对象"的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法却相对稳定。
何时使用：一些基本部件不会变，而其组合经常变化的时候。
如何解决：将变与不变分离开。
应用实例：
- 去肯德基，汉堡、可乐、薯条、炸鸡翅等是不变的，而其组合是经常变化的，生成出所谓的"套餐"。
- JAVA 中的 StringBuilder。
**优点： **
- 建造者独立，易扩展。
- 便于控制细节风险。
**缺点： **
- 产品必须有共同点，范围有限制。
- 如内部变化复杂，会有很多的建造类。
**使用场景： **
- 需要生成的对象具有复杂的内部结构。
- 需要生成的对象内部属性本身相互依赖。
注意事项：与工厂模式的区别是：建造者模式更加关注与零件装配的顺序。
