切面范式
横看成岭侧成峰 ——《苏轼·题西林壁》
引号重开话题：“OOP方兴未艾，AOP又开始崭露头角。AOP算是OOP的一种分支、一种补充还是一种超越？”
叹号故作捶胸顿足状：“OOP还没有完全吃透，又来了个什么AOP。”
“不同的人对新生事物采取不同的态度。”冒号王顾左右而言他，“追星族倾向于盲目追捧，唯恐落伍，他们信奉新潮的流行的就是好的；守旧派倾向于本能抗拒，回避求新，他们认为经典的传统的才是好的。”
引号和叹号互视一眼，不情愿地戴上了老冒派发的帽子。
冒号续道：“从宏观角度看，太阳底下没有新鲜事——AOP无非是SoC原理和DRY原则的一种应用；从微观角度看，太阳每天都是新的——AOP虽自OOP的土壤中长出，却脱离藩篱自成一体，并且嫁接到非OOP的领地，不仅在纯过程式语言、函数式语言、甚至逻辑式语言中得到发展，而且本身也具备了一定的声明式语言特征，成为一种新的软件模块化方式。”
问号举手：“什么是SoC和DRY？”
引号代答：“SoC就是Separation of concerns，即关注点分离；DRY是Don’t Repeat Yourself，即尽量减少重复代码。”
“答案正确，加十分！”冒号戏赞道，“不良代码通常有两种病征：一是纷乱如麻，纠缠打结，可谓剪不断理还乱；二是叠床架屋，臃肿不堪。治疗此类病症一个有效的方法是抽象与分解：从问题中抽象出一些关注点，再以此为基础进行分解。分解后的子问题主题鲜明并且独立，不会牵一发而动全身。同时具有相同特征的部分可以象代数中的公因子一样提取出来，减少了代码重复。”
句号醒悟道：“这不就是模块化吗？”
“准确地说，抽象是前提，分解是方式，模块化是结果。”冒号很讲究精确，“大家记得庖丁解牛的故事吧？在常人眼中复杂的牛体，庖丁经过抽象，已目无全牛，及至提刀分解，自是游刃有余。待牛如土委地，模块化既成。”
句号举一反三：“前面提到的编程范式的基本思想大多不也如此？将程序分别抽象分解为过程、函数、断言、对象和进程，就依次成为过程式、函数式、逻辑式、对象式和并发式。至于泛型式——”
句号讲不下去了。
“泛型式虽未引入新类型的模块，其核心也是抽象出算法后与数据分解。”冒号为其解围，“以此类推，切面式的AOP将程序抽象分解为切面。”
问号提问：“抽象与分解的原则是什么？”
冒号作了个V字：“两条：单一化，正交化。每个模块职责明确专一，模块之间相互独立，即高聚合低耦合（high cohesion & low coupling）。此原则相当普适，是分析复杂事物的一种基本方法，在数学和物理中应用得尤为广泛，如质因式分解、正交分解、谱分解等等。”
逗号调皮地抬杠：“为什么称为正交化呢？斜交化不行吗？”
冒号呵呵一笑：“互为正交的两个向量在彼此方向上投影为零，意味着彼此独立，互不影响，斜交可不行。”
逗号吐了吐舌头。
“诚如前述，AOP以切面为模块。”冒号返回主题，“切面Aspect常直译为‘方面’，但它描述的是横切关注点（Cross-cutting concerns），故‘切面’更准确生动，而‘方面’则失之空泛呆板。何谓横切关注点？顾名思义，乃是与程序的纵向主流执行方向横向正交的关注焦点。不妨回顾一下，无论是过程式的函数，还是对象式的方法，都包含了完整的执行代码。但有些代码横跨多个模块，以片断的形式散落在各处，虽具有相似的逻辑，却无法用传统的方式提炼成模块，难以实现SoC与DRY。典型的例子如：在调用某些对象的方法、读写某些对象的域、抛出某些异常等等前后，需要用到统一的业务逻辑，诸如日志输出、代码跟踪、性能监控、异常处理、安全检查、事务管理等等。为解决此类问题，AOP应运而生。它将每类横切关注点封装到单独的Aspect模块中，将程序中的一些执行点与相应的代码绑定起来。单个的执行点称为接入点（join point），例如：调用某个对象的方法前后；符合预先指定条件的接入点集合称为切入点（pointcut），例如：所有以set为命名开头的方法；每段绑定的代码称为一个建议（advice）。”