第55章设计模式与代码可读性

设计模式与代码可读性：建造者模式简化构造、外观模式封装复杂、模板方法明确流程

代码可读性这件事，我这些年感触特别深。刚入行那会儿，总觉得能跑就行。后来带团队，看别人写的代码，或者回头看自己三个月前写的，经常一头雾水。嗯，这时候才明白——代码首先是写给人看的，顺便给机器执行。

今天聊三个模式，它们对可读性的提升特别直接。说白了，就是让调用方少操心，让流程更清晰。

建造者模式：别让构造器变成参数灾难

你想想看，一个对象如果有七八个字段要设置，用构造器怎么写？要么搞一堆重载，要么传一堆null。我见过最夸张的，一个构造器有12个参数，调用的时候根本分不清哪个是哪个。

建造者模式就是解决这个问题的。它把对象的构建过程拆成链式调用，每一步都清晰明了。

  核心思想：将复杂对象的构建与表示分离，让同样的构建过程可以创建不同的表示。

我在项目中遇到过这样一个场景：配置一个报表引擎，需要设置数据源、过滤条件、排序规则、分页参数、导出格式……如果用构造器，调用方得记住每个参数的位置。用建造者模式就好多了：

// Java 示例
Report report = new Report.Builder()
    .setDataSource("mysql://localhost:3306/sales")
    .addFilter("date >= '2024-01-01'")
    .addFilter("amount > 1000")
    .setSortBy("date", SortOrder.DESC)
    .setPageSize(20)
    .setExportFormat(ExportFormat.PDF)
    .build();

你看，每个步骤都像在说人话。调用方不需要知道Report内部怎么组装，只需要按顺序告诉它「我要什么」。

我的习惯：当构造参数超过3个，或者有多个可选参数时，我就会考虑用建造者模式。别等到参数爆炸了再重构，那会儿改起来就疼了。

外观模式：给复杂系统一个「简单入口」

外观模式，说白了就是封装。把一堆复杂的子系统调用，封装成一个简单的接口。调用方不需要知道背后有多少组件在协作，它只需要调用一个方法。

我曾经接手过一个支付系统，里面涉及账户校验、风控检查、额度计算、渠道路由、日志记录……调用方要完成一笔支付，得调五六个服务，还得自己处理异常。那代码写得，跟蜘蛛网似的。

用外观模式重构后，就变成了这样：

// Java 示例
public class PaymentFacade {
    private AccountService accountService;
    private RiskControlService riskService;
    private RoutingService routingService;
    private AuditService auditService;

    public PaymentResult pay(PaymentRequest request) {
        // 内部协调所有子系统
        accountService.validate(request.getAccount());
        riskService.check(request);
        String channel = routingService.route(request);
        PaymentResult result = channel.process(request);
        auditService.log(request, result);
        return result;
    }
}

// 调用方只需要一行
PaymentResult result = paymentFacade.pay(request);

我曾经踩过的坑：外观模式不是万能胶。别把所有逻辑都塞进外观类里，它只负责编排，不负责实现。否则外观类会变成「上帝类」，比原来还难维护。

外观模式的价值在于：降低认知负担。调用方只需要理解一个接口，而不是整个子系统。这对团队协作特别重要——你写的模块，别人能快速上手。

模板方法模式：把流程「固化」下来

模板方法模式，我愿称之为「流程标准化利器」。它把算法的骨架定义在父类里，让子类去实现具体的步骤。这样，流程是固定的，但细节可以灵活变化。

为什么说它能提升可读性？因为你一眼就能看到整个流程的全貌，不需要钻进每个子类里去猜顺序。

// Java 示例
public abstract class DataImporter {
    // 模板方法，定义了导入流程
    public final void importData(String filePath) {
        openFile(filePath);
        parseData();
        validateData();
        transformData();
        saveToDatabase();
        closeFile();
    }

    // 子类必须实现的步骤
    protected abstract void parseData();
    protected abstract void transformData();

    // 可选钩子方法
    protected void validateData() {
        // 默认实现，子类可覆盖
    }

    // 固定步骤，子类不能修改
    private void openFile(String path) {
        // 打开文件逻辑
    }

    private void saveToDatabase() {
        // 保存到数据库逻辑
    }

    private void closeFile() {
        // 关闭文件逻辑
    }
}

// 具体实现
public class CsvImporter extends DataImporter {
    @Override
    protected void parseData() {
        // 解析CSV格式
    }

    @Override
    protected void transformData() {
        // CSV特有转换
    }
}

你看，importData方法里，六个步骤清清楚楚。新同事看代码，第一眼就知道「哦，导入数据要经过这些步骤」。这就是模板方法的威力——流程即文档。

我建议：模板方法里的步骤，命名要动词开头，比如openFile、parseData。这样读起来就像在念操作手册，可读性直接拉满。

三个模式放在一起看

这三个模式，其实都在解决同一个问题：让代码更容易被理解。只是角度不同：

模式	解决什么问题	提升可读性的方式
建造者模式	构造参数过多、顺序混乱	链式调用，参数名即文档
外观模式	子系统调用复杂、耦合高	统一入口，隐藏内部细节
模板方法模式	流程不清晰、重复代码多	固定骨架，步骤一目了然

我个人习惯，在项目初期就会考虑这些模式。不是过度设计，而是给代码留出「呼吸的空间」。你想想看，一个方法如果超过50行，或者一个类有十几个public方法，读起来是不是很累？这些模式就是帮你把复杂度拆开、封装、固化。

最后说一句：设计模式不是银弹。但如果你想让代码更「好读」，这三个模式绝对是投入产出比最高的。尤其是团队协作时，别人读你的代码，就像在读一篇结构清晰的文章，而不是在解一道谜题。

  一句话总结：建造者模式让构造变简单，外观模式让调用变简单，模板方法让流程变简单。三个模式，都在为「人」服务。

📚 课程目录

设计模式与代码可读性：建造者模式简化构造、外观模式封装复杂、模板方法明确流程

建造者模式：别让构造器变成参数灾难

外观模式：给复杂系统一个「简单入口」

模板方法模式：把流程「固化」下来

三个模式放在一起看