【代码结构设计】优化重构文件夹的树状结构

背景

公司主要做数据治理相关的产品，奈何初期为了追求速度留下了一些饮鸩止渴的设计，后期影响最大的就是文件夹这块，治理数据首先要归档数据，通过文件夹的方式来将同一业务属性的数据收拢到一起。

前期的业务逻辑简单，简单的结构足以满足文件夹树查询、搜索等等需求，但发展到后期越来越多的满足文件夹结构但又不是文件夹的操作增加，比如分类、比如主题等等虽然有父子级关系但数据表不一致的情况。

导致前后端交互上同一个业务逻辑产生不同的数据结构，而且接口也不统一，有些在python服务上，有些在java服务上，每次开发都要写很多重复逻辑的代码复用性很低不通用。

于是乎，高层在某天召开会议，会议内容主要确定全面深化改革文件夹功能，并提出三个全面

• 全面抽象实体
• 全面建设低耦合、高内聚、易扩展接口
• 全面优化加速接口速度

作为新时代夹娃工程师，一定不能辜负组织上交给我的任务，虽然我深知越恶心的功能重构起来坑越多，但这些都难不倒勤劳勇敢的打工人(领导答应搞好给高绩效)。

在之前的代码上优化属于是屎上雕花了，革命就要流血，这次准备直接遗弃掉旧代码，重新抽象好整体文件夹基架。不管业务中到底是不是文件夹都抽象成文件夹，只要文件夹满足父子级关系、并且绑定了一些文件都走同一个逻辑。

全面抽象文件夹实体

标准的数据库结构主要就是三张表，FOLDER表存储文件夹信息、FOLDER_REL表存储文件夹与文件关联表、FILE表存储文件信息。

改版文件夹操作第一步就得先定义出抽象文件夹来，不管数据库中的代码结构和业务含义，只要是可以被抽象成文件夹的都可以按统一的文件夹操作。

主要功能就是抽象代码，把每一步都剥离出来，搞一个策略模式，抽出一个AbstractFolderService抽象类定义方法，提供一个FolderBaseServiceImpl以标准的FOLDER表做基础实现。

方法入参封装一个查询基本信息对象，

@Data
@SuperBuilder(toBuilder = true)
@AllArgsConstructor
@NoArgsConstructor
public static class FolderKey {

    @ApiModelProperty(value = "文件夹id")
    private String folderId;

    @ApiModelProperty(value = "操作文件夹类型")
    private Integer type;

    @ApiModelProperty(value = "企业域id做数据隔离")
    private String entId;
}
复制