企业开发spring框架业务逻辑复用的两个技巧
spring 框架是企业开发最常用的框架，以其高度可定制、可扩展性著称。
典型的 spring mvc 分层架构中，会形成 Controller、Service、Dao 三层。这三层的类实例都会作为 bean实例注册到 spring 的 bean 容器中。
Service 层是非常重要的一层，集中了大量的业务逻辑。普通情况下还好，但是如果你在开发的过程中，遇到有一组 Service 要共用业务数据处理逻辑，但是处理过程又有某些细微不同，这个时候你怎么办？
一般工程师懒得设计的话，就直接将业务数据处理逻辑都在每个 Service 中实现了。但其实有两个常用的技巧去处理这种场景，一个是抽象模板类，另外一个是策略模式。
抽象模板类中一般有个模板方法，封装了数据处理逻辑的模板方法。模板方法会调用类中定义的抽象方法。而这些抽象方法会在继承模板类的子类（Service ）中个性化定制实现。使用子类 Service 的实例，就可以直接调用模板方法了。这种技巧采用了类继承方式。
而策略模式采用的是类组合方式。策略模式主要有两种类，Context类和Strategy类。Strategy接口的实现会作为Context类构造函数的参数。你很容易想到，要复用的数据处理逻辑应该放到Context类的public 方法中，而个性化处理会作为Strategy的接口方法。Context类的数据处理方法会调用Strategy的接口方法。
Strategy接口对应到 spring mvc 中，可以是 Service 接口。在阿里巴巴java 项目分层规范中，除了 Service 层，还有一个 Manager 层，主要职责是 Service 层的一些通用能力下沉。你可以将Context类的实现放到 Manager 中，供那一类Service使用。
这两种业务逻辑复用技巧，我都有在实际项目中用过。但是相对而言，比较喜欢使用策略模式。它是基于组合的方式，比基础方式更灵活一些。