空对象模式：告别空值判断烦恼

空对象模式是一种以“有行为、有语义的默认对象”替代null的设计智慧，专为解决“空值需安全调用却非错误”的业务场景而生——如未登录用户返回NullUser（getName()自动返回“游客”）、无优惠券返回NullCoupon（getDiscount()稳稳返回0.0）、日志关闭时NullLogger静默吞掉所有日志调用；它不掩盖问题，也不滥用默认值，而是通过接口一致、行为合理、零副作用的精心设计，让业务代码摆脱层层判空的泥潭，实现链式调用自然流畅、逻辑清晰可审计；但切记：它只适用于“空即常态”的领域语义，一旦涉及数据缺失风险或本该失败的异常情况，就该果断抛异常或用Optional亮明不确定性。

空对象模式不是用来“消灭 null”，而是把“null 该干的事”变成一个有行为、有语义的对象。它解决的不是语法问题，而是设计问题——当某个对象可能不存在，但调用方又必须能安全调用其方法时，用一个默认行为明确的空对象来承接，就能自然绕过层层 if (obj != null)。

什么时候该用空对象，而不是 Optional 或判空？

关键看“空”是否代表一种有意义的业务状态：

• 用户未登录 → 返回 NullUser，getName() 返回“游客”，getRole() 返回“GUEST”，placeOrder() 静默失败或跳转登录页；这不是异常，是常态
• 订单无优惠券 → 返回 NullCoupon，getDiscount() 返回 0.0，getDescription() 返回“暂无可用优惠”；调用方直接累加，无需分支
• 日志模块未启用 → 返回 NullLogger，所有 info()、error() 方法为空实现；上层完全不感知开关逻辑

如果“空”意味着错误（比如数据库连接丢失、配置项强制必填却缺失），那就该抛异常或用 Optional 显式暴露不确定性，而不是掩盖。

怎么写出真正好用的空对象？

空对象不是“随便返回个默认值”，它得让调用方感觉不到差异：

• 接口一致：和真实对象实现完全相同的接口，连返回类型、参数顺序、异常声明都不能变
• 行为合理：返回值要符合上下文语义——集合类返回空列表（不是 null），数值类返回 0 或 1（非负场景下），字符串类返回 "" 或 "N/A"，布尔类返回 false（除非“默认开启”是业务约定）
• 无副作用：不能修改状态、不发请求、不打日志、不触发回调；它的存在只为“让链式调用不断掉”
• 可识别可调试：重写 toString()，比如 "NullUser{id: -1, name: '匿名'}"；必要时加 isNull() 方法，方便排查

工厂 + 接口 + 空对象，三件套落地最稳

避免在业务代码里 new NullXXX，统一交给工厂管理：

• 定义抽象接口 UserService，含 findUserById(Long)
• 真实实现 DbUserService，查不到就委托给 NullUserService.getInstance()
• 空实现 NullUserService 是单例，所有方法返回安全默认值
• 客户端只依赖 UserService，写 service.findUserById(123).getName().toUpperCase() 就行，完全不用 try/catch 或判空

这种结构天然支持策略切换——灰度期间，工厂可按规则返回 Real 或 Null 实现，业务线无感。

注意边界：别让空对象变成“黑洞”

空对象模式不是银弹，滥用反而掩盖问题：

• 数据库主键查询返回 NullUser？可以，这是常见缺省
• 用户提交表单后，user.getAddress().getCity() 返回 "未知城市" 却继续下单？危险——这已脱离“空”的语义，属于数据缺失风险，应拦截或提示
• 空对象内部偷偷记录埋点或上报监控？违背“无副作用”原则，会干扰可观测性

核心判断标准：调用空对象的方法后，业务流程是否仍能给出**可预期、可解释、可审计**的结果。如果不是，那就不是该用空对象的地方。

以上就是《空对象模式：告别空值判断烦恼》的详细内容，更多关于的资料请关注golang学习网公众号！