我最近读了一篇论文Gregor Kiczales等人的“面向方面的编程”,并在那里找到了循环融合的例子。
本文给出了循环融合的定义。
…该环路融合是通过融合具有相同环路结构且是数据流图中的直接邻居的原始滤波器的循环组成的。当查看自己的适当图片时,这些组合规则中的每一条都很容易理解。但这两种组合关系
在本文后面的文章中,提到了使用Lisp上的元对象协议来实现循环融合:
…环路融合方面的…可以使用CLOS元对象协议中的方法组合工具来实现,具有一定的效率。
在静态或动态类型化语言中使用任何面向方面的现代框架,循环融合是什么样子的?我正在寻找方面语言和建议的例子,可以做循环融合。
1月中旬的
只要没有其他答案,我就把自己的答案标为答案。无论如何,我仍然期待着其他语言/框架的例子。
ps:环融合在"AOP in .NET“图书论坛@manning论坛中的应用
发布于 2013-01-08 10:56:13
在最初的论文发布之后,Gregor已经开始了AspectJ项目,以实现面向方面编程的思想。最近,我发现了为什么“行动中的AspectJ”( Ramnivas Laddad )没有提供“循环融合”的解释:
此外,下面都是连接点:对象构造、条件检查、比较、异常处理程序,甚至还有for、while和do/while循环。并非系统中的所有连接点都可供您使用。…为了防止依赖于实现或不稳定的横切,AspectJ故意只公开系统中所有可能的连接点的一个子集。例如,AspectJ不公开for循环,因为您可以轻松地将for循环更改为以相同方式工作的while循环。如果要进行这样的更改,对于for循环的连接点的所有通知都将不再有效,因为循环将不再存在。
我在接受PostSharp上的Gael Fraiteur采访时发现的另一点是:
一些不同的人也推荐AOP作为功能需求,我.所以在各个方面都很有侵略性。使用PostSharp,您必须设计方面,以便方面不知道它们的目标代码。他们不知道看变量..。所以请注意不要误用PostSharp,不要误用AOP,也要尊重工程原理,尊重关注点的分离,而且在Java中,它的概念要长得多,而且他们对它有很多的实践,用户觉得用方面编程更困难,因为方面必须知道目标代码。他们必须知道目标方法的实现等。目标方法必须知道它们会受到影响。我认为这是一个非常糟糕的设计,当您计划使用AOP时,我建议您设计基本代码和AOP代码,这样它们就不会相互了解了。真正重要的是不要因为一个小小的改变而完全生气。
因此,看起来在AspectJ和PostSharp上都没有“循环融合”,而根据它的定义,动态代理也不能提供这种功能
https://softwareengineering.stackexchange.com/questions/181248
复制相似问题