使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
下面是《设计模式》中给出的适用范围：
1) 有多个的对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定。
2) 你想在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。
3) 可处理一个请求的对象集合应被动态指定

责任链模式由两个角色组成：
1) 抽象处理者角色（Handler）：它定义了一个处理请求的接口。当然对于链子的不同实现，
也可以在这个角色中实现后继链。
2) 具体处理者角色（Concrete Handler）：实现抽象角色中定义的接口，并处理它所负责
的请求。如果不能处理则访问它的后继者。

//这是抽象处理者角色
public interface CodeAutoParse {
//这里就是统一的处理请求使用的接口
String[] generateCode(String moduleCode, int number, String rule,String[] target)
throws BaseException;
}
//这个为处理日期使用的具体处理者
public class DateAutoParse implements CodeAutoParse{
//获取当前时间
private final Calendar currentDate = Calendar.getInstance();
//这里用来注入下一个处理者，系统中采用Spring Bean 管理
private CodeAutoParse theNextParseOfDate;
public void setTheNextParseOfDate(CodeAutoParse theNextParseOfDate){
this.theNextParseOfDate = theNextParseOfDate ;
}
/*
*实现的处理请求的接口
*这个接口首先判断用户定义的格式是否有流水号,有则解析,没有则跳过
*下传到下一个处理者
*/
public String[] generateCode(String moduleCode, int number, String rule, String[]
target)
throws BaseException {
//这里省略了处理的业务
……
if(theNextParseOfDate != null)
return theNextParseOfDate.generateCode(moduleCode , number , rule,
target)
else
return target;
}
责任链模式优点，上面已经体现出来了。无非就是降低了耦合、提高了灵活性。但是责
任链模式可能会带来一些额外的性能损耗，因为它每次执行请求都要从链子开头开始遍历。   代理模式有俩个英文名字：Proxy Pattern SurrogatePattern
  定义：为期货对象提供一种代理以控制对这个对象的访问。说白了就是，在一些情况下客户不想或
者不能直接引用一个对象，而代理对象可以在客户和目标对象之间起到中介作用，去掉客户
不能看到的内容和服务或者增添客户需要的额外服务。
JAVA与模式中将代理模式分为8种：常见的有1.远程代理(remote)；2.虚拟代理（virtual）；3.保护代理(Protect or Access);
4.智能引用(Smart Reference)代理等。
结构：
1.抽象主题角色：声明了真实主题和代理主题的共同接口。
2.代理主题角色：内部包含对真实主题的引用，并且提供和真实主题角色相贩接口。
3.真实主题角色：定义真实的对象

class Subject
{
public:
 Subject(){}
 virtual ~Subject(){}

 virtual void Request() = 0;
};

// 真正使用的实体
class RealSubject
 : public Subject
{
public:
 RealSubject();
 virtual ~RealSubject(){}

 virtual void Request()
｛
std::cout << "Request By RealSubject\n";
｝
};

// 代理类,含有一个指向RealSubject对象的指针
class Proxy
 : public Subject
{
public:
 Proxy()
 : m_pRealSubject(NULL)
{
 std::cout << "Constructing a Proxy\n";
}
 virtual ~Proxy()
{
 delete m_pRealSubject;
 m_pRealSubject = NULL;
}

 virtual void Request()
{
 // 需要使用RealSubject的时候才去初始化
 if (NULL == m_pRealSubject)
 {
  std::cout << "Request By Proxy\n";
  m_pRealSubject = new RealSubject();
 }
 m_pRealSubject->Request();
}

private:
 RealSubject* m_pRealSubject;
};

int main()
{
 Subject* pProxy = new Proxy();
 pProxy->Request();

 delete pProxy;

 return 0;
}

五、总结
代理模式能够协调调用者和被调用者，能够在一定程度上降低系统的耦合度。代理模式
中的真实主题角色可以结合组合模式来构造，这样一个代理主题角色就可以对一系列的真实
主题角色有效，提高代码利用率，减少不必要子类的产生。 定义：采用一个共享类来避免大量有相同内容的”小类“的开销。。这种开销中最常见、直观的影响就是增加了内存的损耗。享元模式以共享的方式高效的支持大量
的细粒度对象，减少其带来的开销。
在名字和定义中都体现出了共享这一个核心概念，那么怎么来实现共享呢？事物之间都是不同的，但是又存在一定的共性，如果只有完全相同的事物才能共享，那么享元模式可以说就是不可行的；因此我们应该尽量将事物的共性共享，而又保留它的个性。为了做到这点，享元模式中区分了内蕴状态和外蕴状态。内蕴状态就是共性，外蕴状态就是个性了。内蕴状态存储在享元内部，不会随环境的改变而有所不同，是可以共享的；外蕴状态是不可以共享的，它随环境的改变而改变的，因此外蕴状态是由客户端来保持（因为环境的变化是由客户端引起的）。在每个具体的环境下，客户端将外蕴状态传递给享元，从而创建不同的对象出来。
享元模式分为：单纯享元模式和复合享元模式。
结构：
单纯享元模式的结构
1.抽象享元角色：为具体享元角色规定了必须实现的方法，而外蕴状态就是以参数的形式通过此方法传入。
2.具体享元角色：实现抽象角色规定的方法。如果存在内蕴状态，就负责为内蕴状态提供存储空间。
3.享元工厂角色：负责创建和管理享元角色。要想达到共享的目的，这个角色的实现是关键！
4，客户端角色：维护对所有享元对象的引用，而且还需要存储对应的外蕴状态。
复合享元模式的结构
1.抽象享元角色：为具体享元角色规定了必须实现的方法，而外蕴状态就是以参数的形式通过此方法传入。
2.具体享元角色：实现角色规定的方法。如果存在内蕴状态，就负责为内蕴状态提供存储空间。
3.复合享元角色：它所代表的对象是不可以共享的，并且可以分解成为多个单纯享元对象的组合。
4。享元工厂角色：负责创建和管理享元角色。要想达到共享的目的，这个角色的实现是关键。
5.客户端角色：维护对所有享元对象的引用，而且还需要存储对应的外蕴状态。

class Flyweight{
public:
 virtual ~Flyweight(){}
 string GetIntrinsicstring()
{
return m_State;
}
 virtual void Operation(string & ExtricState) = 0;
protected:
Flyweight(const string & state)
:m_state(state)
{}
private:
string m_state;
};

class FlyweightFactory
{
public:
FlyweightFactory(){}
~FlyweightFactory(){

std::list<Flyweight*>::iterator iter1, iter2, temp;

 for (iter1 = m_listFlyweight.begin(), iter2 = m_listFlyweight.end();
  iter1 != iter2;
  )
 {
  temp = iter1;
  ++iter1;
  delete (*temp);
 }

 m_listFlyweight.clear();
}
Flyweight* GetFlyweight(const string& key)
{

std::list<Flyweight*>::iterator iter1, iter2;

 for (iter1 = m_listFlyweight.begin(), iter2 = m_listFlyweight.end();
   iter1 != iter2;
   ++iter1)
 {
  if ((*iter1)->GetIntrinsicState() == key)
  {
   std::cout << "The Flyweight:" << key << " already exits"<< std::endl;
   return (*iter1);
  }
 }

 std::cout << "Creating a new Flyweight:" << key << std::endl;
 Flyweight* flyweight = new ConcreateFlyweight(key);
 m_listFlyweight.push_back(flyweight);
}
private:
list<Flyweight*> m_listFlyweight;
};

class ConcreateFlyweight:public Flyweight
{
public:
ConcreateFlyweight(const string& state)
:Flyweight(state)
{}
virtual ~ConcreateFlyweight(){}
virtual voidOperation(string & ExtriunsiState)
{

}
}
void main()
{
FlyweightFactory flyweightfactory;
 flyweightfactory.GetFlyweight("hello");
 flyweightfactory.GetFlyweight("world");
 flyweightfactory.GetFlyweight("hello");
}
//感觉例子举的不是很好  以后在改
五、使用优缺点
享元模式优点就在于它能够大幅度的降低内存中对象的数量；而为了做到这一步也带来
了它的缺点：它使得系统逻辑复杂化，而且在一定程度上外蕴状态影响了系统的速度。
所以一定要切记使用享元模式的条件：
1)系统中有大量的对象，他们使系统的效率降低。
2)这些对象的状态可以分离出所需要的内外两部分。
外蕴状态和内蕴状态的划分以及两者关系的对应也是非常值得重视的。只有将内外划分
妥当才能使内蕴状态发挥它应有的作用；如果划分失误，在最糟糕的情况下系统中的对象是
一个也不会减少的！两者的对应关系的维护和查找也是要花费一定的空间（当然这个比起不
使用共享对象要小得多）和时间的，可以说享元模式就是使用时间来换取空间的。可以采用
相应的算法来提高查找的速度。

定义：动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。
组成：
1.抽象构件角色(Component):定义一个抽象接口，以规范准备接收附加责任的对象。
2.具体构件角色(Concrete Component):这是被装饰者，定义一个将要被装饰增加功能的类。
3.装饰角色(Decorator)：持有一个构件对象的实例，并定义了抽象定义的接口。
4.具体装饰角色(Concrete Decorator)：负责给珈增加的功能。

//抽象基类，定义一个对象接口，可以为这个接口动态的添加职责。
class Component{
public:
Component(){}
virtual ~Comonent(){}
//纯虚函数，由派生类实现
vitual void Opation() = 0 ;
};

//抽象基类，维护一上指向Component对象的指针
class Decorator:publc Comonnt{
publc:
Decorator (Componnt* pComponent)
{

}
virtual ~Component(){
 delete m_pComponent;
 m_pComponent = NULL;
}

protected:
Compponnt *m_pComponent;
};

// 派生自Component,在这里表示需要给它动态添加职责的类
class ConcreateComponent
 : public Component
{
public:
 ConcreateComponent(){}
 virtual ~ConcreateComponent(){}

 virtual void Operation()
{
cout << "Operation of ConcreateComponent\n";
}
};

// 派生自Decorator,这里代表为ConcreateComponent动态添加职责的类
class ConcreateDecorator
 : public Decorator
{
public:
 ConcreateDecorator(Component* pComponent) : Decorator(pComponent){}
 virtual ~ConcreateDecorator(){}

 virtual void Operation()
{
m_pComponent->Operation();
 AddedBehavior();
}

private:
 void AddedBehavior()
{
cout << "AddedBehavior of ConcreateDecorator\n";
}
};

void main()
{

// 初始化一个Component对象
 Component* pComponent = new ConcreateComponent();
 // 采用这个Component对象去初始化一个Decorator对象,
 // 这样就可以为这个Component对象动态添加职责
 Decorator* pDecorator = new ConcreateDecorator(pComponent);

 pDecorator->Operation();

 delete pDecorator;

 system("pause");

 return 0;
｝
透明和半透明
对于面向接口编程，应该尽量使客户程序不知道具体的类型，而应该对一个接口操作。
这样就要求装饰角色和具体装饰角色要满足Liskov 替换原则。像下面这样：
Component c = new ConcreteComponent();
Component c1 = new ConcreteDecorator(c);
JUnit 中就属于这种应用，这种方式被称为透明式。而在实际应用中，比如java.io 中往
往因为要对原有接口做太多的扩展而需要公开新的方法（这也是为了重用）。所以往往不能
对客户程序隐瞒具体的类型。这种方式称为“半透明式”。

//和我之前看的一个版本代码不是太一样，有点迷糊。说说我的想法和感受。从代码的结构来看，装饰者模式有一个主抽象基类Component，定义了一接口。有一个派生抽象在，维护了基类指针Decorator。派生类又有派生类
（ConcreateDecorator）用来实现Decorator;主抽象基类Component还有一个派生类用来基类接口，动态添加职责。

将一个类的接口转换成客户希望的另外一个接口。Adapter械使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
组成：
1目标(Target):定义Client使用的接口。
2被适配(Adaptee)角色：这个角色有一个已存在并使用了的接口，而这个接口是需要我们适配的。
3适配器（Adapter）角色：这个适配器模式的核心。它将被适配角色已有的接口转换为目标希望的接口。
在《设计模式》一书中将适配器模式分为类适配器模式和对象适配器模式。区别仅在于适
配器角色对于被适配角色的适配是通过继承完成的还是通过组合来完成的

// 需要被Adapt的类
class Target
{
   public:
Target(){}
~Target(){}
virtual void Request() = 0;
};

// 与被Adapt对象提供不兼容接口的类
class Adaptee
{
public:
 Adaptee(){}
 ~Adaptee(){}
 void SpecialRequest();
};

// 进行Adapt的类,采用聚合原有接口类的方式
class Adapter
 : public Target
{
private:
 Adaptee* m_pAdptee;
public:
 Adapter(Adaptee* pAdaptee)
: m_pAdptee(pAdaptee)
{
}
 virtual ~Adapter()
{
delete m_pAdptee;
 m_pAdptee = NULL;
} 
virtual void Request()
{
std::cout << "Request of Adapter\n";

 m_pAdptee->SpecialRequest();
}
};

void main()
{
Adaptee *pAdaptee = new Adaptee();
 Target * pTarget = new Adapter();
 pTarget->Request();
delete pAdaptee;
delete PTarget;
}
//感觉这个就是一个抽象基类  我去实现个派生类 来实现那个接口
//派生类里面有个另个类的成员变量  然后通过该接口的实现 去调用另一个类的方法
//为什么不直接在基类中实现呢？？？不是很懂  慢慢学习中