外观模式，简化20行代码？

说实话，这玩意儿听起来有点高大上。

但其实它就是把一堆乱七八糟的子系统调用，装进一个小盒子里。

你只要敲几句代码，底层那一堆复杂操作就全自动搞定。

哈哈，我跟你讲，这种感觉就像打开外卖盒子，里面全是热腾腾的饭菜，你根本不用管厨师怎么翻锅。

先摆个场景，咱们来感受一下

想象一下你在写个视频转码工具。

原始实现可Neng得调音频编码器、视频编码器、文件IO、日志系统……每个dou要实例化、配置，还得捕获异常。

代码行数轻轻松松冲到二三十行。

结果呢？每改动一次dou得去找所有调用点，一不小心就踩坑。

外观模式登场！

我们把这些子系统全部包进一个叫 MediaFacade 的类里。

对外只暴露 Encode 一个方法。

客户端只需要三行：

facade := NewMediaFacade
err := facade.Encode
if err != nil { /* 处理错误 */ }

哎呀，不对不对，应该是先创建实例，再调用，细节我这里省略哈。

整个过程从二十多行压到不到十行，你说气不气？

为啥说“简化20行代码”这么夸张？

因为真正的业务往往比示例geng繁杂。

比如电商下单：

public OrderResult createOrder {
    FlightCache flight = resolveFlight;
    PriceVerifyResult price = verifyPrice;
    if ) return OrderResult.priceMismatch;
    SeatLockResult seat = lockSeat;
    if ) return OrderResult.seatUnavailable;
    Order order = orderService.createOrder;
    messageService.sendOrderCreated);
    auditLogService.logOrderCreate, req);
    return OrderResult.success;
}

kan着dou头疼，对吧？

把它们抽出来塞进 OrderFacade，外部只要一句：

result = orderFacade.createOrder;

这下子，从二十几行降到一行，爽歪歪！

别让 Facade 变成上帝类

咱们老友记里常说“好兄弟别抢风头”。

Facade 只Neng负责“编排”，别把业务规则塞进去。

业务该放 Service 那儿，Facade 就别动手脚。

#啰嗦一下#：Ru果你在 Facade 里写了 if-else 判断，那基本上Yi经越界了。业务逻辑应该交给对应的 Service 去处理。

怎么避免 Facade 失控？

- 按业务拆分多个 Facade

- 每个 Facade 方法保持单一职责

- 子系统的变化尽量不影响 Facade 接口

- 用依赖注入，把子系统实例交给 Facade，而不是在内部 new

"为什么百度不收录"——顺带聊聊 SEO 小技巧

为什么百度不收录我的页面？

哈哈，这问题跟我们今天聊的外观模式有点像——dou是“入口”没弄好导致“内容”没人kan到。

- 页面没有