exodia / aop Goto Github PK

两种方案：

1. 初始化时执行: 创建代理，遍历被拦截对象的所有属性，符合 matcher 的就在代理上 override。
   该方案优势在基本于无性能影响，但缺少从被拦截对象获取当前状态的功能。 适用于 string 和 RegExp 的matcher。
2. 调用方法时执行：创建代理，override 被拦截对象的所有方法，在 override 的方法中加入 matcher 的检查。
   该方案缺点是对性能有一定影响，优势在于能够从被拦截对象上获取一些当前信息，根据信息动态改变匹配规则。 适用于 Function matcher

目前还不确定function matcher 是否要用方案2.

advice与装饰器的关系：

• aop 提供各个advice的装饰器，使用方自行调用
• aop 提供从装饰器生成 advice 的功能（DecoratorAdvice）

Object method API 的拦截方式：

• 直接修改原对象：支持场景如方法执行次数统计
• 返回高阶对象的方式：支持场景如需要使用原有对象方法

resolvedBy: #4

针对 Class 的装饰器做在哪个层面？ ioc，aop 或者第三方？

ioc 层面提供的 advice 是基于函数粒度的，还是基于组件(Class)粒度的

之前讨论有两种方案：

1. 直接修改原有对象
2. 返回代理对象

现打算采用方案2，理由如下：

• 方案1对 freeze object 无效
• 倾入性太强，对问题的排查干扰性较大
• 基于方案2， 使用者可以明确原对象与拦截代理对象之间的差异，能够在原对象与代理对象之间灵活的切换，且能够基于原对象继续封装出服务于其他模块的另一个代理对象
• 针对要对原对象方法调用次数统计的场景，应直接在任何依赖原对象的模块中使用统计代理对象替换。

一个简单的例子：

let toAdvise = {
    method() {
         console.log('method called');
    }
};

let advisedObject = aop.before(toAdvise, 'method', function beforeAdvice(...args) {
      console.log('before method call');
      console.log(args.toString());
});

// before method call
// a
// method called
advisedObject.method('a');

// method called
toAdvise.method('a');