面向对象拦截器设计：增强对象行为方法

本文深入探讨了一种真正面向对象的拦截器设计范式——它摒弃了传统AOP依赖代理与反射的黑盒机制，转而通过组合、递归和接口契约，在编译期构建清晰可溯的行为嵌套链；每个拦截器是具备状态、依赖和策略能力的完整对象，天然支持前置/后置逻辑的严格逆序执行、异常补偿、流程终止与跨场景复用（Web、CLI、RPC等），不仅零运行时代理开销、堆栈直观、易于测试，更以“让对象自身可插拔”为核心，重新定义了横切关注点在OOP体系中的自然落脚方式。

拦截器在面向对象架构中，不是给方法“加钩子”，而是让对象自身具备可插拔的行为扩展能力。它的核心不在于代理或反射，而在于用组合+递归+接口契约，把横切逻辑自然地编织进对象生命周期里。

拦截器本质是对象行为的“嵌套封装”

一个 Target 对象不直接被调用，而是被包装进 TargetInvocation 实例中。这个包装体持有一个 Interceptor 列表和一个 Target 引用。当执行时，它不是顺序遍历列表，而是递归调用：当前拦截器的前置逻辑 → 下一层（下一个拦截器或 target）→ 当前拦截器的后置逻辑。这种结构天然支持嵌套、可撤销、可跳过——比如某个拦截器 preHandle 返回 false，就直接终止递归，不再往下传。

• 每个 Interceptor 实现统一接口（如 before/after），但内部可自由访问上下文、调用 service、修改参数或响应
• TargetInvocation 不依赖 Spring 或 Servlet 容器，纯 Java 对象，可单元测试、可复用到 CLI 或消息处理等非 Web 场景
• 新增拦截逻辑只需实现接口 + 插入链中，无需修改原有 Target 类，符合开闭原则

与 AOP 和动态代理的关键区别

Spring AOP 基于代理，是在运行时生成新类；而 OOP 拦截器是编译期确定的组合关系。前者强依赖反射和类加载机制，后者只依赖接口和引用传递。这意味着：

• 没有代理类生成开销，启动快、内存占用低
• 调试时堆栈清晰：能看到每一层 InterceptorImpl → TargetInvocation → Target 的完整调用路径
• 不绑定框架：同一套 Interceptor 可用于 Spring MVC、Vert.x、甚至自研 RPC 调用链

如何组织拦截逻辑才真正“面向对象”

避免把拦截器写成一堆静态工具方法的集合。真正 OOP 的写法是：每个拦截器是一个有状态、可配置、可复用的对象。

• 用构造函数或 Builder 注入依赖（如 Logger、UserService），而不是靠 @Autowired 或静态单例
• 将判断逻辑封装为策略，例如 AuthInterceptor 内部持有 AuthStrategy 接口，不同环境切换 JwtStrategy / SessionStrategy
• 利用 ThreadLocal 或上下文对象（如 InvocationContext）传递数据，而非在 request/response 中塞临时属性

递归调用不是炫技，而是为了行为对称性

preHandle 和 afterCompletion 必须成对出现，且执行顺序严格逆序。递归天然保证这一点：进入时层层 before，退出时层层 after，像括号匹配一样可靠。

• 若用循环实现，需额外维护栈或索引，容易遗漏后置逻辑或顺序错乱
• 异常传播也更自然：某层抛出异常，上层可在 after 中捕获并做补偿（如回滚事务、释放锁）
• 支持“环绕式”语义，比如 PerformanceInterceptor 记录耗时，不需要拆成两个独立阶段

今天关于《面向对象拦截器设计：增强对象行为方法》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！