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的可保持状态有什么区别。哈哈。。。。等等这些,只不过是范型的一角,路还很远啦。 而且这些讨论必须是基于语言语意级的,而非二进制组件级的,不然会天下大乱了。