MordernC++Design设计新思维之读书笔记1-Policy

MCD学习笔记
1．Policy
       个人感觉policy更像是一种静态的调用规范。指定一个模板类，它含有某种格式的接口，然后分发给很多的实现厂商，然后这些厂商去通过这个静态的接口的规范来实现出满足不同需求的实现商品出来。
       可以让人联想到的是Factory模式（参见GOF，下面简称F），在F中，某个系统工程师制定了一个框架结构，在这个框架中，需要一个能够生产出几种不同组件产品的工厂，于是它先不管这个工厂的具体实现，它首先假定有了这样的一个工厂，（定义这样的一个工厂的虚基类，在这个虚基类当中将所有的需要生产的各种组件的方法设置为虚函数），然后将这个工厂的接口公布给底下去实现该接口的工厂1，工厂2等等，其后这些虚接口和配套的说明文件就是这些工厂的设计指导。这些工厂拿到这些说明后通过这个虚基类去派生出各自的实现类。最后负责组装的工程师通过只需要通过让自己的需要用到这些工厂的指针或者是引用指向这些工厂的对象，通过动态机制，就可以实现系统的轻松配接。

        而在Policy当中，这种Factory模式是静态产生的，所谓静态，是指在程序编译完毕后就已经产生。如WidgetManger<class CreatePolicy>类中，需要提供能够产生不同种CreatePolicy的类，然后每个这样的类都必须实现一个Create的方法。在组装的时候，系统工程师就可以绕过CreatePolicy的具体类的实现来实现其它的功能。在WidgetManager内部，凡是需要用到CreatePolicy的地方可以使用该CreatePolicy的一个对象来产生Create()。这个Create()一直不做任何事情，直到它被实例化后才有自己的价值。在这过程当中也可以就让WidgetManager就继承于CreatePolicy.

       在Policy中，定义的template<template <class Created> Class CreationPolicy>class WidgetManager中的意义如下：Created是CreationPolicy的模板参数，而CreationPolicy又是WidgetManager的模板参数，在这个模板的申明中，可以不用将这几个参数加上。因此就如同下面定义函数void funcA(int A,void*B(int C,int D))一样，这些A，B，C，D都是funcA的参数一样，在此函数的申明的时候A,B,C,D都可以不用一样。

       如果为policy定义了一个虚的析构函数的话，会妨碍policy的静态连结特性，也会影响到执行效率。但是可以通过定义一个保护的非虚的析构函数来实现对模板类对象的析构。

       建立Policy的准则是：将参与class行为的设计鉴别出来并且命名之，只要任何一种事情有一种以上的方法去解决，那都应当被分析出来建立它的Policy Class.

       需要注意的事：最好不同的Policy Class之间不存在有耦合，如果真的必须出现耦合，那么具体应该怎样去做，希望哪位高手能够给以解答，这也是困绕我地方。解决方法是否如下：比如PolicyA类需要用到PolicyB类的相关的状态，那么在定义PolicyA类的时候在模板参数列表当中加入PolicyB，然后在需要PolicyB相关状态的地方放入对PolicyB引用(Bridge模式的应用)，该引用以接口参数的形式导入？
 
       原来上面说的注意事项在1.12中已经讲出，在书上讲的正交设计和非正交设计，分别对应的是耦合和非耦合。
      

      总结：Policy机制是由template和多重继承组成。Policy和传统的Factory模式很像,Policy接口的特点是：它比较松散。只是在编译时期决定它的指向，而传统的Factory模式是在执行时期才决定。Policy为我们提供了一种非常便利，非常可靠的组件的组装思想。将class分解成为policies的两条重要的准则是：第一：把你的class肉的“设计决定”局部化，命名，分离出来。第二：找出正交的policies。
       TAGS：GOF，设计模式，工厂模式，C++，Policy，接口，框架，虚基类，耦合，Bridge模式，正交设计。