谈谈"基于策略编程"的看法，以及concept、aop

wingfiring (非典型秃子) 等　级： 结帖率：100.00%

楼主发表于：2004-10-27 12:42:33 第一次接触到 "基于策略编程 "是来自于MCD(morden   c++   design). 之前，了解过一些关于concept的概念， 之后，又听说了一些AOP（面向方面编程）的东西。 在实际应用中，感觉的 "基于策略编程 "还是很有威力的。 但是，这个传统的OO有很大的区别，个人认为，基于策略编程   =   ADT(抽象数据类型）   +   算法，这样概括似乎比简单的说OO   +   template更精确一些。 而且，这里的adt和算法，又可以通过concept来表达。 至于AOP，我所知甚少，欢迎达人指教。个人感觉，concept的再泛化、再抽象，就类似AOP了。 例如：约定说组件要提供一个create方法，可以算是concept；约定说：要提供创建策略，是不是就可以算是AOP了？ 工作中的点滴想法，希望抛砖引玉，欢迎达人们指教、讨论。

Polarislee (北极星) 等　级：

#2楼 得分：0回复于：2004-10-27 14:21:08 所谓基于策略的编程实际上可以看作是，Strategy   Pattern的一个静态实现，它保留了Strategy   Pattern的一些优点——实现策略与算法解耦，去掉了它的一些缺点——除掉了委托，提高了效率，不过也丧失了Strategy   Patter的策略可替换的优点。

Polarislee (北极星) 等　级：

#3楼 得分：0回复于：2004-10-27 14:26:42 AOP的主要思想在于处理横切的关注点，主要是一些执行过程中的通用任务，比如：日志记录，实物管理等等，这些操作在进行任何操作的前后都要执行，即使将他们抽象出来作为函数也必须在每次使用时进行调用，也就是说让与真正任务无关的代码掺入了程序之中，增加了程序的复杂性。 AOP就是为了解决这些问题的，AOP将这些通用的横切任务分离出来，然后通过某种方式（比如配置）将这些代码掺入到真正的业务代码之中。现在的AOP主要是应用在一些可以动态进行代码编织的语言中，比如：Java。在C++中实现真正的AOP好像还是有一些困难的

Wolf0403 (Wolf0403) 等　级：

#4楼 得分：0回复于：2004-10-27 14:27:51 嘿嘿。。。interface   是个好东西。C++   的   Pure   virtual   base   class   不错，可惜总是要涉及到继承、虚函数等等细节，所以干脆出现了   MCD   式样的模板做法 AOP   的着眼点在于动态吧。

plainsong (短歌) 等　级： 2 2 2

#5楼 得分：0回复于：2004-10-27 16:08:08 我和星星的看法一样，认为“基于Policy的编程”其实就是泛型的“Strategy模式”，是希望利用“Strategy模式”的部分优点又不愿付出多态的代价的产物。

wingfiring (非典型秃子) 等　级：

#8楼 得分：0回复于：2004-10-28 09:18:54 Strategy模式在其他语言中，我不清楚如何运用。 就C++而言，动态的运用Strategy模式往往存在如下问题：一组动态可替换的策略之间，必须有公共的基类，也就必须在设计基类的时候就确定这个策略类提供哪些方法。 而运用concept概念的Policy则不同，遵循“行为像什么，它就是什么”的原则，同一组策略只要遵循一个命名协议就可以了，这一组类不必要求什么有公共基类。此外，得益于template的“用到了才实例化”，如果在某个地方，并没有用到policy的某个方法，那么，我完全可以把一个缺乏该方法的policy类扔进去使用。 另外，还有一个重要的，也是我喜欢policy的根本原因： 不同的策略方面，往往代表了一些细节，而这些细节是最终程序员用户最清楚自己要什么样的行为。policy则可以将决定policy需要哪些方法的决定权交给了最终用户，而Strategy则必须早早的在设计基类的时候就加以定义。 如果另一个程序员用户认为：需要对某个policy扩展新的方法，那么，他只要产生一个新的policy，并扩展方法就可以了。而Strategy类则必须：1修改Strategy基类，2可能要修改所有的派生类。

Jinhao (某些人不敢再叫鸡了) 等　级：

#9楼 得分：0回复于：2004-10-28 19:14:55 关于“接口” 基于policy编程   有个优点就是不在为   policy   class   没有某个“接口”而担心。policy   class是不会暴露出去的，它只在类中起作用。不像在OO中，会因为一个(虚)基类中没有某个(pure)virtual   function而又不能修改这个类层次而烦劳。前者的解决方法只需要对原先的policy   class做个简单的继承，得到一个具有新方法的policy   class，而后者就要麻烦得多，比如可以考虑用Visitor模式来解决。 但实际上，基于policy编程和OO编程没有本质上的联系。我认为在   基于policy编程中，接口就像是遵循一种协议，只要你遵循这个协议，我并不在于你这个policy   class的行为，我只需要对我有用的policy   class。但是在OO中，要考虑类层次，所以你不能随意给某个类设定额外的职责，遵循这个接口的初衷是必须考虑的。 上面我并不是把基于policy编程和OO编程作比较，只是在形式上的一点区别。 在C++中，使用动态绑定来实现派生类特定的操作。对于下面这种情况“派生类可以覆盖，也可以不覆盖我，随你的便。但是你不可以调用我的实现”，我们可以在基类中使用private   virtual   function来完成。其实这个问题也同样存在于   基于policy的编程中。比如我们要利用到一个存在的policy   class，但是只需要修改其中一个或几个少数的同名方法，那么我们完全不用去为了一个或少数方法的改变而粘贴/复制一个新的policy   class出来，只需要用继承+Name   Hiding就行了 还有就是，MCD中解释了Policy的出现是为了解决多重继承带来的负面影响，但是我觉得它并不与多重继承有什么冲突，只是它们所在的问题域不同，Policy注重于实现可配接的行为组件，专注于一个特定的任务,   而class在Policy中只起到一个载体的作用，而不是一种抽象。

sandrowjw (九目人) 等　级：

#10楼 得分：0回复于：2004-10-31 12:42:50 如果真的要实现动态的多态的话，分支结构是无法避免的，不管是用什么形式。 但是在静态框架的构件上policy更加清晰和高效，能使组件有更好的适应性。 实际上我觉得policy/concept的抽象方式更接近于程序员的思考方式，而传统oo更接近于问题的描述。

wingfiring (非典型秃子) 等　级：

#12楼 得分：0回复于：2004-11-08 09:22:37 > policy/concept的抽象方式更接近于程序员的思考方式，而传统oo更接近于问题的描述 概括的很精炼！ 问题在于：在这两者处理的问题上面，是程序员的思考方式好，还是OO比较好？或者，还是那句老话：适合的就是最好的，什么合适就用什么？ 鸡丁说的private   virtual   function   +   Name   Hiding，其运作过程我好像想不大明白。 老大是不是可以说得详细一点？最好举个例子^_^

Polarislee (北极星) 等　级：

#13楼 得分：0回复于：2004-11-09 15:50:42 需要对某个policy扩展新的方法，那么，他只要产生一个新的policy 并不这么简单，如果你要利用新的policy定义的新方法就必须要为这个policy定义定义一个模板的特例化版本

Waitan (大雾) 等　级：

#15楼 得分：0回复于：2004-11-24 22:01:16 Polarislee(北极星)(灌水是我无言的抗议)关于AOP的说法应该没有什么问题。 在我的项目中，也曾为错误处理，日志系统等煞费苦心。感觉AOP在处理上相当于由编译器，或者织入器也好，在你指定的位置，插入你指定的代码，仔细想来，不够神秘，开发人员应该不用担心过于复杂不容易设计的问题。只要我们等到好的编译器，甚至，我们可以自己在源码层（二进制层可能难度大些）作些开发，制作出一个织入器，来处理我们的代码。注意：一定要小心，而且，能织入，也应该能清理啊！

babysloth (小懒虫虫) 等　级：

#18楼 得分：0回复于：2005-01-03 15:21:30 policy是静态的，设计之初已经意识到了所谓aspect或者policy或者strategy的存在。添加或者删除policy是很困难的。AOP应该是动态的。这是从概念上，个人理解。（AOP当然也可以静态weave进去，但是觉得不爽，呵呵。）

zhaoli (木灵光) 等　级：

#19楼 得分：0回复于：2005-01-03 17:17:20 我认为，AOP主要靠类型的运行时行为实现的，在AOP中的类型应该是在运行时可变的，而且可一演绎，拆分

tangzhige (咯么弱) 等　级：

#20楼 得分：0回复于：2005-01-29 16:35:22 我认为问题在于：       AOP动态与静态在语义上是否有根本区别（就像动多态与静多态一样）。动多态与静多态在语意上是不同的。这从根本上来说是由于对象状态可以持续保持造成的，这样才会出现所谓的Runtime。但是需要深思的是所谓的AOP，在对类型泛化后，有没有可保持的状态，而且是否需要可保持的状态，如果有，可保持的泛化状态又是什么，这些与OO的可保持状态有什么区别。哈哈。。。。等等这些，只不过是范型的一角，路还很远啦。     而且这些讨论必须是基于语言语意级的，而非二进制组件级的，不然会天下大乱了。