在java编程，如何避免代码耦合度高、冗余的建议

前言：

        在日常编程中，总是会存在一些代码明明可以抽离出来作为公共方法，却硬要写在一起，导致同段代码，东一块，西一块的，极其难维护，可读性也几乎为零，那么结合自身，有如下几个建议，仅供参考。

---

建议1：

        场景：现有一个保存的接口，接口参数只有一个ID，很多地方调用了这个接口，那么现在有另一个地方要调用该接口，但接口参数不只是ID了，还需要多传一个NAME，如果把保存接口的代码复制多一份，只增加一个接收参数的话，那么当处理逻辑一变，两个接口就都得变了，这是极其不合理的行为，可以通过如下方式避免：

        解决思路：将现有的接口A抽离出来作为公共接口C，接口参数定义为ID、NAME两个，原有的接口A调用接口C，参数NAME不存在时，则传入null，新增的接口B也调用接口C，传入对应的ID和NAME即可，这样如果处理逻辑变了，就只需要更改接口C的代码逻辑即可，不需要再接口A和接口B同时修改。

        伪代码： 

public void a(Integer id){
    c(id, null); //调用c方法
}

public void b(Integer id, Integer name){
    c(id, name); //调用c方法
}

/**
 * 共用的方法
 * @param id
 * @param name
*/
public static void c(Integer id, Integer name){
    // TODO: 2022/9/29 处理逻辑
}

---

建议2：

        场景：（该场景要结合mybatis-plus考虑，不知道是啥的，请转MyBatis-Plus）一般情况下，我们在使用mp做数据库操作时，都会利用它优秀的机制做分页操作，业务处理层只需要传入页数和页码即可实现分页操作，很方便，但是如果要实现列表做导出所有时，则会出现一个问题，即mp自带的IPage工具类是需要页数和页码的，不传则会报异常，传了又要怎么传参，才能实现导出所有数据的功能呢？思路如下：

         解决思路：既然mp的分页规则是固定的，那么就可以通过查看它的源码，了解它的分页方式实现，如图一，页数和页码虽说是固定必传的，但是current的是大于1的，那么可以通过修改页数和页码的传入值大小实现不走分页的方法

public Page(long current, long size, long total, boolean isSearchCount) {
        if (current > 1) {
            this.current = current; //这里！！！
        }
        this.size = size;
        this.total = total;
        this.isSearchCount = isSearchCount;
}

         伪代码：关闭分页，current=-1, size=-1

@Override
public ServiceResponse getList(TeamGridLeaderSearchVo searchVo) {
    searchVo.setCurrent(-1); //这里的值可以后端设置，也可以通过前端传入
    searchVo.setSize(-1); //这里的值可以后端设置，也可以通过前端传入
    IPage<TeamGridLeaderListVo> page = gridLeaderMapper.selectPage(searchVo);
    return ServiceResponse.createSuccessByData(page);
}

---

建议3：

        a.对于一些常用且多处业务层都引用的、且变化性不强的方法，如时间处理、excel导出等，最好是单独剥离出来作为一个工具类，切勿反复造轮子，尽量做到一处维护，多处生效。

        b.对于一些状态值，如1、2、3等，可以通过设置公共常量或者枚举维护，不要每个文件一堆的setType(1)，写了注释还好，不写注释的话，谁那么有空花时间去了解这个1是啥意思呢？只会增加开发成本，降低开发效率。

---