• 时间:
  • 分类:

当前公司的业务代码中存在类似一下的代码逻辑：
一个代码解析器 然后内部存在一个不断增长的解析代码

public class CodeParser{

    static parseHtml();
    static parseCSS();
    static parseJSP();
    static ParseJAVA();
    static ParsePython();
}

原有的 CodeParser 类将 多种代码解析逻辑集中在一个类中，通过静态方法区分不同解析方式。

随着解析类型的增加，这种写法会带来：

  • 单个类职责不断膨胀
  • 不同解析逻辑相互耦合
  • 可读性、可测试性下降
  • 新增解析类型需要频繁修改当前的 CodeParser

那么如何重构代码呢？

二、原始设计的问题

1. 职责过于集中

public class CodeParser {
    parseHtmlCode(...)
    parseCSS(...)
}
  • 一个类承担了多种不相关的解析规则
  • 修改任一解析逻辑，都需要修改同一个类

2. 扩展方式不可控

当需要支持新的解析类型（如 Vue / React / Markdown）时：

  • 只能继续在 CodeParser 中新增方法
  • 类会持续膨胀
  • 违反 开闭原则（OCP）

三、重构的核心思路

将不同的解析逻辑拆分成独立的类，每个类只负责一种解析方式，从而提升可维护性和扩展性。

四、重构后的设计思路

1. 抽象解析行为

将“解析代码”抽象为一个统一接口：

public interface CodeParser<T> {
    T parse(String content);
}

表达的设计意图是：

“代码解析是一种行为，可以有多种实现。”

2. 拆分不同解析实现

HTML解析
public class HtmlCodeParser implements CodeParser<HtmlCodeResult> {
    @Override
    public HtmlCodeResult parse(String content) {
        
    }
}
CSS 解析
public class CSSCodeParser implements CodeParser<CSSCodeResult> {
    @Override
    public CSSCodeResult parse(String content) {
        
    }
}

每个解析类：

  • 只关注自身规则
  • 互不影响

五、重构的好处

1. 可维护性显著提升

  • 每个解析逻辑独立
  • 避免误修改其他解析逻辑

2. 扩展成本更低

新增解析类型时：

class VueCodeParser implements CodeParser { ... }

无需修改已有解析类。

3. 为未来演进留好空间

后续如果需要：

  • 自动识别解析类型
  • 引入 Router / Registry
  • 接入第三方解析库（再引入 Adapter）

当前结构 无需推倒重来。

六、与 Adapter / Strategy 的关系说明

当前阶段

  • 不是 Adapter 模式
  • 因为不存在“被适配的第三方接口”
  • 所有解析逻辑均为系统内部可控实现

未来可能演进

当引入第三方解析库时：

ThirdPartyParser -> CodeParser

此时才会自然引入 Adapter。

七、总结

**本次重构的目的，是将不同代码解析逻辑按职责拆分，
降低单个类复杂度，提高系统的可维护性与可扩展性。**

标签: none

添加新评论