Aspectj 实现Method条件运行

  面对这样的需求初级程序员有些人肯定会觉得没什么了不起的啊，不就是几个if/else或者switch/case。我和我的团队对代码有一种天生的洁癖，对于太多复杂的if/else和switch/case，以及将来会被移除的临时非产品代码分布在各处，有一种抵触心理。

对于有一定工作经验的程序员来说这样的需求肯定也不是什么问题，不就是aop（面向切面编程），对，这就是我们所期望的解决方案，把处理的逻辑集中，和产品代码的分离。

知道了用aop，也许你只对了一半，在aop的世界里，有两种实现方式静态植入和动态代理，最早了aop实现采用的是静态植入，然后由于ioc之类的框架的兴起，动态代理的实现方式也逐渐兴起，取代了静态植入的方式。但并不是说静态植入的方式就不再有用武之地的，在这里我们所采用的aop框架aspectj就是一个静态注入的框架，我们并没有和spring结合，动态代理的方式有个基本的问题就是你不能直接new这个对象这需要交给框架处理，如果是spring框架的话，这要求你必须是一个spring的bean，以及动态代理会有一些性能的损失。这对于该场景的限制太多，并不是我所期望的。

这里简述如何实现：

1 对于aop第一步是匹配规则，所以定义一个标记：

其指向一个实现runner接口的类型。

2：有了匹配规则，我们就可以找到切入点进行aop逻辑的处理，

  这里在切入方法调用之前，new了一个配置的runner类型（注意必须午餐构造），并调用其exec方法获取是否运行该方法，如果不运行则返回什么默认值。

exec的参数签名为方法签名信息和方法运行时参数。

    一切都这么简单，现在你可以任意的框架runner去做适合你的场景业务了。可以参照项目下得sample实例，该实例展示了一个当出入参数为3的时候执行，部位3则返回默认值1.

   想想还有那些场景，你是否遇见过某类单元测试我只希望运行在某种固定的场景下？假设在开发图形应用的时候，我们希望调用一些不同平台的特定api，虽然我们代码设计封装做得很好，但是我们希望有固定的集成测试去cover这部分逻辑，让我们的测试只运行是固定平台。