An example of using policy strategy patterns in design patterns in C + + programming to explain _c language

Looking at "C + + Design new thinking", found in the beginning of a large length of the introduction of the Strategy Model (policy), the strategy model is not a classic design pattern, but in fact, in our day-to-day development is essential. Policy, strategy, policy, the meaning here is that the complex function of the class as far as possible to split into a single function of a simple class combination, simple class is only responsible for the simple behavior or a certain aspect of the structure. Increase the flexibility, reusability and scalability of the library. Policy is a virtual concept, he defined a class of some interface specification, does not correspond to the C + + syntax keyword, but an abstract concept.

Example 1:

Common usages of policy patterns smartptr,
template
<
  class T,
  template <class> class Checkingpolicy,
  template <class> class ThreadingModel
>
class smartptr
  : Public checkingpolicy<t>
  , public threadingmodel<smartptr>
{  
  t* operator-> ()
  {
   typename Threadingmodel<smartptr>::lock Guard (*this);
   Checkingpolicy<t>::check (pointee_);
   return pointee_;
  }
Private:
  t* pointee_;

Example 2, for example: we define a policy, he is a template with a parameter T, he must have a CREATE function, and return the T type pointer. For this definition, we can have different implementations to meet the different needs of different users.

Template <class t> struct Opnewcreator {static t* Create () {return new T;

}
};
   Template <class t> struct Malloccreator {static t* Create () {void* buf = std::malloc (sizeof (T));
   if (!BUF) return 0;
  return new (BUF) T;

}
}; Template <class t> struct Prototypecreator {prototypecreator (t* = 0):p pobj (prototype_) {} pobj Create (
  ) {return pprototype_ pprototype_->clone (): 0;
  } t* Getprototype () {return pprototype_;}
void Setprototype (t* pobj) {pprototype_ = pobj;} private:t* pprototype_;

};

Test class class Widget {};
Call method One: template <class creationpolicy> class Widgetmanager:public Creationpolicy {};


void Main () {typedef widgetmanager< opnewcreator<widget> > Mywidgetmgr;
//Call Method two: Because the general manager is specific to a class, the manager specifies the class type to be processed. Template <template <class created> class creationpolicy> class Widgetmanager:public creationpolicy<
widget> {}; void Main() {//Application code typedef widgetmanager<opnewcreator> MYWIDGETMGR;}

 

There are 3 different implementations of the above strategy to meet the needs of different customers.
But for the above use, we can also have a better change: because the policy implementation class is generally inherited, so we have to consider his destructor, the general we make the destructor virtual, but here will affect the static compiler characteristics of template, affect efficiency, So we use protected or private destructor, which does not affect the destructor of the inheriting class to the base class, nor does it affect the use.
If modified as follows:

Template <class t>
struct opnewcreator
{
  static t* Create ()
  {return
  new T;
  }
Protected:
  ~opnewcreator () {}
};

We can also modify the above manger to implement the switch for creator policy:

Template <template <class> class creationpolicy>
class Widgetmanager:public creationpolicy< widget>
{ 
  void Switchprototype (widget* pnewprototype)
  {
   creationpolicy<widget>& MyPolicy = *this;
   Delete Mypolicy.getprototype ();
   Mypolicy.setprototype (Pnewprototype);
  }
;

The policy model plays a very important role in the development of reusable, extensible libraries, and is one of the basic principles of OO.

Overall policy pattern:
Advantages:
1, use the policy mode to avoid the use of multiple conditional transfer statements. Multiple transfer statements are not easy to maintain.
2, the policy model allows you to dynamically change the behavior of the object, dynamic modify the policy

Disadvantages:
1. The client must know all the policy classes and decide which policy class to use.
2, too many classes---the policy model causes a lot of policy classes, each specific policy class will produce a new class. (This can be done by using the meta pattern to overcome too many classes)