C++博客-只有面对现实，你才能超越现实-随笔分类-Design Pattern

设计模式之strategy

王海光 — Tue, 17 Jul 2012 00:11:00 GMT

一、概述
Strategy（策略）模式又称Policy模式，用于定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换。这里的算法并非狭义的数据结构或算法理论中所讨论的KMP、shell sort等算法，而是指应用程序设计中不同的处理逻辑，前面所说的狭义的算法只是其中的一部分。Strategy模式使得算法与算法的使用者相分离，减少了二者间的耦合度，使得算法可独立于使用它的客户而变化；同时，由于设计粒度的减小，程序的复用性也得到了进一步提高，分离出来的算法可以更好地适应复用的需要。

二、结构
Strategy模式的结构如下图所示：

从结构上看，Strategy模式与State模式有几分相似，但二者所讨论的Context（情景）具有显著的差异：
State模式在于将其状态信息分离出来保存到一个独立的对象中，以便状态信息的获取或状态的转换；Strategy模式在于将可能的算法分离出来，根据需要进行适当的选择。此外，二者的区别还在于，Strategy模式中各个Strategy（算法、策略）往往用于解决相同的问题，即只是解决同一问题的不同“策略”、“途径”，而且，一次只能有一个Strategy为上次应用提供服务；而State模式中的各个State本身往往具有一定的差异，但他们之间存在明显的相互转换的关系，而且这种转换往往会在程序运行过程中经常性地发生，同时存在一个以上State也是可能的。

区别参考：二者的应用场合不同。状态模式用于处理对象有不同状态（状态机）的场合，策略模式用于随不同外部环境采取不同行为的场合。在状态模式中，状态的变迁是由对象的内部条件决定，外界只需关心其接口，不必关心其状态对象的创建和转化；而策略模式里，采取何种策略由外部条件决定。所以，有人说“状态模式是完全封装且自修改的策略模式”。至于Bridge，在结构上与前两者都不一样了。要说相似之处，就是三者都有具有对外接口统一的类，展现出多态性而已。

三、应用
当存在以下情况时可考虑使用Strategy模式：
1.许多相关的类仅仅是行为有异。“策略”提供了一种用多个行为中的一个行为来配置一个类的方法。
2.需要使用一个算法的不同变体。例如，你可能会定义一些反映不同的空间/时间权衡的算法，当这些变体实现为一个算法的类层次时，可以使用策略模式。
3.算法使用客户不应该知道的数据。可使用策略模式以避免暴露复杂的、与算法相关的数据结构。
4.一个类定义了多种行为，并且这些行为在这个类的操作中以多个条件语句的形式出现。将相关的条件分支移入它们各自的Strategy类中以代替这些条件语句。
更具体的应用实例包括：
1.以不同的格式保存文件；
2.以不同的方式对文件进行压缩或其他处理；
3.以不同的方式绘制/处理相同的图形数据；
等等。

四、举例
下面是一个应用Strategy模式对vector进行排序的例子，为了简化问题，其中的排序Strategy实际上调用的是STL的排序算法：sort和stable_sort。

  1 #include <iostream>
  2 #include <vector>
  3 #include <algorithm>
  4 #include <time.h>
  5 using namespace std;
  6
  7 template <typename T>
  8 class SortStrategy    // Strategy
  9 {
10 public:
11     virtual void Sort( vector<T>& v_t ) = 0;
12 };
13
14 template <typename T>
15 class SortQuick : public SortStrategy<T>    // ConcreateStrategy1
16 {
17 public:
18     void Sort( vector<T>& v_t ) { std::sort( v_t.begin(), v_t.end() ); }
19 };
20
21 template <typename T>
22 class SortStable : public SortStrategy<T>    // ConcreateStrategy1
23 {
24 public:
25     void Sort( vector<T>& v_t ) { std::stable_sort(v_t.begin(), v_t.end()); }
26 };
27
28 template <typename T>
29 class Context {        // Context, who or whose client takes charge of which strategy will be selected
30 public:
31     Context() { m_pStrategy = NULL; }
32     virtual ~Context() { if (m_pStrategy != NULL) delete m_pStrategy; }
33
34     void SetStrategy(SortStrategy<T>* pStrategy);    // select a strategy
35
36     void ReadVector( vector<T>& v_t);
37     bool SortVector();
38     void OutputVector();
39 private:
40     vector<T> m_vt;
41     SortStrategy<T>*  m_pStrategy;    // a pointer to current strategy
42 };
43
44 template <typename T>
45 void Context<T>::SetStrategy( SortStrategy<T>* pStrategy )
46 {
47     if ( NULL != m_pStrategy )
48         delete m_pStrategy;
49
50     m_pStrategy = pStrategy;
51 }
52
53 template <typename T>
54 void Context<T>::ReadVector( vector<T>& v_t)
55 {
56     m_vt.clear();
57     copy( v_t.begin(), v_t.end(), back_inserter( m_vt ) );
58 }
59
60 template <typename T>
61 bool Context<T>::SortVector()
62 {
63     if ( NULL == m_pStrategy )
64         return false;
65
66     m_pStrategy->Sort( m_vt );
67
68     return true;
69 }
70
71 template <typename T>
72 void Context<T>::OutputVector()
73 {
74     copy( m_vt.begin(), m_vt.end(), ostream_iterator<T>( cout, " " ) );
75 }
76
77 // a functor to generate random int
78 struct RandGen
79 {
80     RandGen(int ratio) { m_ratio = ratio; }
81     int operator() () { return rand() % m_ratio + 1; }
82 private:
83     int m_ratio;
84 };
85
86 int main()
87 {
88     const int NUM = 9;
89     vector< int > vi;
90     time_t t;
91     srand( (unsigned) time(&t) );
92
93     // create a vector with random information
94     vi.reserve(NUM + 1);
95     generate_n(back_inserter(vi), NUM, RandGen(NUM));
96
97     Context< int >  con;
98     con.SetStrategy( new SortQuick<int>() );
99     con.ReadVector( vi );
100     con.OutputVector();
101
102     cout << endl;
103
104     con.SortVector();
105     con.OutputVector();
106
107     return 0;
108 }

本文转自：http://blog.csdn.net/haiyan0106/article/details/1651797

王海光 2012-07-17 08:11 发表评论

C++设计模式-Iterator

王海光 — Mon, 16 Jul 2012 00:11:00 GMT

一、概述
Iterator（迭代器）模式又称Cursor（游标）模式，用于提供一种方法顺序访问一个聚合对象中各个元素, 而又不需暴露该对象的内部表示。或者这样说可能更容易理解：Iterator模式是运用于聚合对象的一种模式，通过运用该模式，使得我们可以在不知道对象内部表示的情况下，按照一定顺序（由iterator提供的方法）访问聚合对象中的各个元素。
由于Iterator模式的以上特性：与聚合对象耦合，在一定程度上限制了它的广泛运用，一般仅用于底层聚合支持类，如STL的list、vector、stack等容器类及ostream_iterator等扩展iterator。
根据STL中的分类，iterator包括：
Input Iterator：只能单步向前迭代元素，不允许修改由该类迭代器引用的元素。
Output Iterator：该类迭代器和Input Iterator极其相似，也只能单步向前迭代元素，不同的是该类迭代器对元素只有写的权力。
Forward Iterator：该类迭代器可以在一个正确的区间中进行读写操作，它拥有Input Iterator的所有特性，和Output Iterator的部分特性，以及单步向前迭代元素的能力。
Bidirectional Iterator：该类迭代器是在Forward Iterator的基础上提供了单步向后迭代元素的能力。
Random Access Iterator：该类迭代器能完成上面所有迭代器的工作，它自己独有的特性就是可以像指针那样进行算术计算，而不是仅仅只有单步向前或向后迭代。
这五类迭代器的从属关系，如下图所示，其中箭头A→B表示，A是B的强化类型，这也说明了如果一个算法要求B，那么A也可以应用于其中。

图1、五种迭代器之间的关系
vector 和deque提供的是RandomAccessIterator，list提供的是BidirectionalIterator，set和map提供的 iterators是 ForwardIterator，关于STL中iterator的更多信息。
二、结构
Iterator模式的UML结构如下图所示：

三、应用
Iterator模式有三个重要的作用：
1）它支持以不同的方式遍历一个聚合复杂的聚合可用多种方式进行遍历，如二叉树的遍历，可以采用前序、中序或后序遍历。迭代器模式使得改变遍历算法变得很容易: 仅需用一个不同的迭代器的实例代替原先的实例即可，你也可以自己定义迭代器的子类以支持新的遍历，或者可以在遍历中增加一些逻辑，如有条件的遍历等。
2）迭代器简化了聚合的接口有了迭代器的遍历接口，聚合本身就不再需要类似的遍历接口了，这样就简化了聚合的接口。
3）在同一个聚合上可以有多个遍历每个迭代器保持它自己的遍历状态，因此你可以同时进行多个遍历。
4）此外，Iterator模式可以为遍历不同的聚合结构（需拥有相同的基类）提供一个统一的接口，即支持多态迭代。
简单说来，迭代器模式也是Delegate原则的一个应用，它将对集合进行遍历的功能封装成独立的Iterator，不但简化了集合的接口，也使得修改、增加遍历方式变得简单。从这一点讲，该模式与Bridge模式、Strategy模式有一定的相似性，但Iterator模式所讨论的问题与集合密切相关，造成在Iterator在实现上具有一定的特殊性，具体将在示例部分进行讨论。

四、优缺点
正如前面所说，与集合密切相关，限制了 Iterator模式的广泛使用，就个人而言，我不大认同将Iterator作为模式提出的观点，但它又确实符合模式“经常出现的特定问题的解决方案”的特质，以至于我又不得不承认它是个模式。在一般的底层集合支持类中，我们往往不愿“避轻就重”将集合设计成集合 + Iterator 的形式，而是将遍历的功能直接交由集合完成，以免犯了“过度设计”的诟病，但是，如果我们的集合类确实需要支持多种遍历方式（仅此一点仍不一定需要考虑 Iterator模式，直接交由集合完成往往更方便），或者，为了与系统提供或使用的其它机制，如STL算法，保持一致时，Iterator模式才值得考虑。

五、举例
可以考虑使用两种方式来实现Iterator模式：内嵌类或者友元类。通常迭代类需访问集合类中的内部数据结构，为此，可在集合类中设置迭代类为friend class，但这不利于添加新的迭代类，因为需要修改集合类，添加friend class语句。也可以在抽象迭代类中定义protected型的存取集合类内部数据的函数，这样迭代子类就可以访问集合类数据了，这种方式比较容易添加新的迭代方式，但这种方式也存在明显的缺点：这些函数只能用于特定聚合类，并且，不可避免造成代码更加复杂。

STL的list::iterator、deque::iterator、rbtree::iterator等采用的都是外部Iterator类的形式，虽然STL的集合类的iterator分散在各个集合类中，但由于各Iterator类具有相同的基类，保持了相同的对外的接口（包括一些traits及tags等，感兴趣者请认真阅读参考1、2），从而使得它们看起来仍然像一个整体，同时也使得应用algorithm成为可能。我们如果要扩展STL的iterator，也需要注意这一点，否则，我们扩展的iterator将可能无法应用于各algorithm。

以下是一个遍历二叉树的Iterator的例子，为了方便支持多种遍历方式，并便于遍历方式的扩展，其中还使用了Strategy模式（见笔记21）：
（注：1、虽然下面这个示例是本系列所有示例中花费我时间最多的一个，但我不得不承认，它非常不完善，感兴趣的朋友，可以考虑参考下面的参考材料将其补充完善，或提出宝贵改进意见。2、我本想考虑将其封装成与STL风格一致的形式，使得我们遍历二叉树必须通过Iterator来进行，但由于二叉树在结构上较线性存储结构复杂，使访问必须通过Iterator来进行，但这不可避免使得BinaryTree的访问变得异常麻烦，在具体应用中还需要认真考虑。3、以下只提供了Inorder<中序>遍历iterator的实现。）

1 #include <assert.h>
2
3 #include <iostream>
4 #include <xutility>
5 #include <iterator>
6 #include <algorithm>
7 using namespace std;
8
9 template <typename T>
10 class BinaryTree;
11 template <typename T>
12 class Iterator;
13
14 template <typename T>
15 class BinaryTreeNode
16 {
17 public:
18      typedef BinaryTreeNode<T> NODE;
19      typedef BinaryTreeNode<T>* NODE_PTR;
20
21      BinaryTreeNode(const T& element) : data(element), leftChild(NULL), rightChild(NULL), parent(NULL) { }
22      BinaryTreeNode(const T& element, NODE_PTR leftChild, NODE_PTR rightChild)
23          :data(element), leftChild(leftChild), rightChild(rightChild), parent(NULL)
24      {
25          if (leftChild)
26              leftChild->setParent(this);
27          if (rightChild)
28              rightChild->setParent(this);
29      }
30
31      T getData(void) const { return data; }
32      NODE_PTR getLeft(void) const { return leftChild; }
33      NODE_PTR getRight(void) const { return rightChild; }
34      NODE_PTR getParent(void) const { return parent; }
35      void SetData(const T& data) { this->data = item; }
36      void setLeft(NODE_PTR ptr) { leftChild = ptr; ptr->setParent(this); }
37      void setRight(NODE_PTR ptr) { rightChild = ptr; ptr->setParent(this); }
38      void setParent(NODE_PTR ptr) { parent = ptr; }
39 private:
40      T data;
41      NODE_PTR leftChild;
42      NODE_PTR rightChild;
43      NODE_PTR parent;   // pointer to parent node, needed by iterator
44
45      friend class BinaryTree<T>;
46 };

本文转自：http://www.cnblogs.com/berry/archive/2009/10/12/1581554.html

王海光 2012-07-16 08:11 发表评论

singleton模式

王海光 — Fri, 13 Jul 2012 00:14:00 GMT

singleton模式是Gof提出的23中模式之一，也称为单例模式，那么简单说一下，什么叫单例模式呢？
通常我们创建类的对象是使用new Object()，然后就调用该对象里面的方法，那么当我们多次使用new Object()的话，会对系统资源造成一种浪费，当然.net内部已经有垃圾回收机制可以处理这种浪费。当然我们并不会再程序里面多次使用new Object()，但是，作为一个类的设计者，我们需要负什么责任，除了让别的模块可以调用使用之外，我们的设计还需要一种规范，这也是OO里面的规范，singleton模式在这里派上了用场。

      singleton模式的意图：确保一个类只能拥有一个实例，并保证逻辑的正确性以及良好的效率，并提供一个该实例的全局访问点。
      singleton模式类型：单线程singleton，多线程singleton
      singleton思路：要让使用者只能使用一个实例的话，那么必须绕过常规的公有缺省构造器

singleton代码：

1 public class singleton
2 {
3     private static singleton instance;
4     private singleton() { }
5     public static singleton Instance
6     {
7         get
8         {
9             if (instance == null)
10             {
11                 instance = new singleton();
12             }
13             return instance;
14         }
15     }
16 }
17

      第4行：利用私有构造函数绕开系统自带的缺省公有构造函数，这样就使类的外部不可以直接使用new实例化对象
      第5行：提供一个静态的公有属性，供类外部调用
      第9行：在这里可能存在BUG，当有两个线程同时操作公有属性时，常规的话应该返回两个一样的实例，但是假如当第一个实例还未来得及创建时，第二个线程又访问了它，显然也会执行　　　　          new singleton（）这个语句，那么这两个对象的引用就不一样了，可以使用object.ReferenceEquals测试一下对象的引用是否一样。因此，给大家提供多线程方案，请看下面代码

1 public class singletons
2 {
3     private static volatile singletons instances = null;
4     private static object lockHelper = new object();
5     private singletons() { }
6     public static singletons Instance
7     {
8         get
9         {
10             if(instances==null)
11             {
12                 lock (lockHelper)
13                 {
14                     if(instances==null )
15                     {
16                         instances = new singletons();
17                     }
18                 }
19             }
20             return instances;
21         }
22     }
23 }

      显然看起来与单线程singleton差不多，多了volatile 修饰符，还有一个Object对象，接下来跟大家解释使用这些其中的缘由
      volatile 修饰符
      假如我定义两个变量和两个属性

1  int a;
2  volatile int b;
3  public int GetFirst
4  {
5      get { return a; }
6  }
7  public int GetSecond
8  {
9      get { return b; }
10  }

GetFirst会得到当前线程中a的值，而多个线程就会有多个a的变量拷贝，而且这些拷贝之间可以互不相同，换句话说，另一个线程可能改变了它线程内的a值，而这个值和当前线程中的a值不相同，那么就造成线程冲突了。
那么再来看看b，因为volatile 修饰的变量不允许有不同于“主”内存区域的变量拷贝，换句话说，一个变量经volatile 修饰后在所有线程中都是同步的；任何线程改变了它的值，所以其他线程立即获取到了相同的值，当然加了volatile 修饰的变量存储时会比一般变量消耗的资源要多一点。

Object对象锁
对象锁可以保证Lock里面的代码只能同时让一个线程执行，所以确保了一个对象只存在一个实例。

同样的需求可以有不同的方法实现，以下是另外一种实现singleton模式的代码，代码更简单，不够有缺陷，请看

1 public class singletonss
2  {
3      public static readonly singletonss Instance = new singletonss();
4      private singletonss() { }
5  }

首先定义一个静态的只读实例，当然也需要私有构造器绕过缺省构造器，这样子也可以保证多线程里也只诞生一个对象实例，因为.Net类型初始化机制保证只有一个线程执行了静态构造器。当然这么少的代码也可以实现singleton，但是静态构造器不支持参数，也不能重构，因为在.Net机制里面只允许一个类拥有一个静态构造器而且是私有的，外部不能调用只能供系统调用，所以我们不能使用参数。

本文转自：http://www.cnblogs.com/magicchaiy/archive/2010/12/02/1894826.html
其他链接：http://www.cppblog.com/dyj057/archive/2005/09/20/346.html

王海光 2012-07-13 08:14 发表评论

C++设计模式之一工厂模式（简单工厂、工厂和抽象工厂）

王海光 — Thu, 12 Jul 2012 00:44:00 GMT

摘要: 今天开始这个系列之前，心里有些恐慌，毕竟园子里的高手关于设计模式的经典文章很多很多，特别是大侠李会军、吕震宇老师的文章更是堪称经典。他们的文笔如行云流水，例子活泼生动，讲解深入浅出。好在他们都是用C#描述，也没有提供必要的源码下载，所以我这里用C++实现。首先我想声明的是我的文笔绝对不如他们的好，例子也没有他们的形象，不过我打算把C+... 阅读全文

王海光 2012-07-12 08:44 发表评论

Active Object 模式

王海光 — Wed, 11 Jul 2012 00:14:00 GMT

Active Object 模式是Command模式的一种，是实现多线程控制的一项古老技术 .

在《敏捷软件开发》这本书中描述的算法如下：
1、构造一个命令。（实现Command模式的一个命令）
2、将该命令放入Active Object Engine（也就是放入一个队列，LinkedList）
3、从该Engine取出一个命令，执行，若该命令没有执行过，设为执行过，然后将自己加入队列尾部，若执行过，判断该命令执行需要的事件发生没有，未发生，再将自己加入队列尾部。事件发生了，将需要执行的命令加入队列尾部。

Active Object模式不属于《Design Pattern》23模式。实际上，她是一种特殊的Command Queue。其特殊之处在于：

1. 队列的拥有者会顺序地执行队列中所有Command对象的Execute方法。（这个其实不算特殊）

2.Command对象在自己的Execute方法结束前，可以把一个新的command对象（实际上常常是这个command对象自己）再加到队列的尾部。

看出来了吗，这个队列有可能不会终止的，他可以一直执行下去。这个可以作为一个应用或者服务的主模块了，想像一下她可以作多少事情吧。

《ASP》指出这个模式可以用来在一个线程中处理多任务的问题！！！ ^_^ 太cool了。

如何处理呢？你可以把每个command对象看作是一个任务。他在Execute函数中，处理自己的任务，在任务告一段落时，记录自己的状态，然后把自己插入到队列的尾部，结束Execute方法。当队列轮完一周后，又会再次执行这个command对象的Execute方法。 ^_^ 很cool吧。

那么这种方法和多线程的方法相比有什么有缺点呢？

最大的优点是，所有的command都在同一个线程中，因此切换时，不需要进入内核模式！！超高效啊！！而且，可以有很多很多的command，数量上远远超过多线程的数量。

缺点嘛，是这种方法需要用户自己来实现调度，另外这其实是一种非剥夺模式的多任务，如果command处理不好，就会连累其它所有的command，因此实际上比多线程要更复杂。（嘿嘿，程序员能够怕麻烦吗？）

还有一点，Active Object运行于单线程，也就是说，她不能享受多处理器或多处理器核心带来的性能上的改善。

其实，这最后一点是非常致命的一点。也就是说，在当前intel的超线程CPU机器上，如果系统的负担并不重的时候。Active Object的效率有可能比多线程更低。

Anyway，这是一个非常有趣的模式。只是一般的程序员可能没有机会用到。

本文转自：http://www.cppblog.com/tx7do/archive/2010/02/28/108617.aspx

王海光 2012-07-11 08:14 发表评论

Command 模式

王海光 — Tue, 10 Jul 2012 05:40:00 GMT

摘要: 引言提起Command模式，我想没有什么比遥控器的例子更能说明问题了，本文将通过它来一步步实现GOF的Command模式。我们先看下这个遥控器程序的需求：假如我们需要为家里的电器设计一个远程遥控器，通过这个控制器，我们可以控制电器(诸如灯、风扇、空调等)的开关。我们的控制器上有一系列的按钮，分别对应家中的某个电器，当我们在遥控器上按下“On”时，电器打开；当我们按下... 阅读全文

王海光 2012-07-10 13:40 发表评论