接囗设计

最新推荐文章于 2025-08-08 14:05:29 发布

外外外

最新推荐文章于 2025-08-08 14:05:29 发布

阅读量222

点赞数

CC 4.0 BY-SA版权

分类专栏：设计模式文章标签：接囗设计策略模式开关

本文链接：https://blog.youkuaiyun.com/qq_39172525/article/details/86658745

设计模式专栏收录该内容

3 篇文章

订阅专栏

接囗设计

把系统分为service层、serviceImpl层，
service层：对外的接口，
serviceImpl层：处理各种业务逻辑，主要是数据校验、数据查询和组装、数据的新增与更新。

一、接囗设计

产品服务层的接口服务遵循request-response风格，每个方法的入参都是一个request，出参都是response。request和response通过继承和组合进行扩展

1.接囗传参可以通过继承扩展

request往往可以通过继承进行不同业务的扩展，例如发货接囗的传参为类A，现在要新加一种业务类型的包裹，外部运单的包裹，类A定义的字段并不能满足外部运单所需要传递的数据，这时就可以定义一个类B，让其继承A，然后把外部运单包需要的多余的数据定义的类B中，然后利用java多态的特性来传递参数

2.接囗传参可以通过开关提升性能（查询接囗）

查询接囗在设计时可以添加一些开关来提升性能，例如一个订单查询接囗可以通过添加 是否需要包裹信息，配件明细信息等减少不必要的查询，提升查询速度，如下。

public class OrderFillingParam implements Serializable {

    /**
     * 是否需要简单的订单明细信息.
     */
    private boolean needOrderDetail;

    /**
     * 是否需要组织信息
     */
    private boolean needOrg;

    /**
     * 是否需要会员级别信息
     */
    private boolean needOrgMemberLevel;

    /**
     * 是否需要订单的订货信息
     */
    private boolean needBookGoods;
}

3.接囗返回值可以通过组合扩展

response往往可以通过组合来扩展不同的业务，比如用户物流单详情页，需要展示物流单信息、用户信息和地址信息，我们可以定义一个OrderDetailResponse，这个对象组合了LogisticsOrderDTO、UserDTO、AddressDTO等对象。

二、接囗实现的设计：策略模式路由+公共方法抽象

对于serviceImpl层，经常遇到各种if else嵌套，每次改一点都需要测试回归整块业务，其改进方式一般是通过策略模式路由+公共方法抽象。

serviceImpl的业务逻辑抽象为四个步骤：校验、查询、封装、执行。

线上单的包裹有线上单包裹的校验、查询、封装、执行，线下单的包裹有线下单的包裹的校验、查询、封装、执行，service调用serviceImpl的时通过策略模式路由。这样各个业务都有不同的代码流程，修改相映的业务只需回归相关业务类型的场景即可，新增业务线也需要添加一条业务流程然后配置一下路由就可以了，不影响既有业务。

策略模式路由可能会使各业务流程在数据校验，查询，封装阶段出现重复代码，这里可以将这些重复的代码拆分成一个个小功能抽象出去，可样做既可以使代码更加清晰，也可在将来要添加某些查询时减少改动点(只改抽象出去的方法即可)。