软件设计：十行代码，装下一套变化应对术

软件设计不是画UML图，也不是把设计模式挨个用一遍。它只解决一件事：当需求变化时，你改的代码越少越好。代码写得越多越容易，写得越少越难。真正的设计功力，往往藏在“少写十行，多想十分钟”里。

一、设计的本质：隔离变化

需求永远会变。今天用邮件通知，明天要加短信；今天打八折，明天要满减。如果每变一次，你都翻遍所有文件改if-else，说明设计已经失败了。

好的设计，是把“容易变的部分”关进独立的房间。房间之间只留一扇小门，门后怎么装修，外面不用知道。这就是高内聚、低耦合。

二、一个最小原则：依赖倒置

高层模块不该依赖低层模块，两者都该依赖抽象。翻译成人话：别在业务代码里直接 new 具体工具。

比如用户注册后要发通知。很多人的第一版会这样写：

class UserService:
    def register(self, user):
        EmailSender().send(f"欢迎 {user}")

这行代码把UserService和EmailSender焊死了。明天要换成短信，你就得改UserService。正确做法是让它依赖一个抽象接口。

三、少量代码：策略模式替代 if-else

下面这段代码只有十几行，却展示了软件设计最实用的套路：把变化封装成对象，让调用方只依赖抽象。

class Notifier:
    def send(self, msg): ...

class EmailNotifier(Notifier):
    def send(self, msg): print("Email:", msg)

class SmsNotifier(Notifier):
    def send(self, msg): print("SMS:", msg)

class UserService:
    def __init__(self, notifier: Notifier):
        self.notifier = notifier

    def register(self, user):
        self.notifier.send(f"欢迎 {user}")

现在，想换通知方式，只需在创建UserService时传入不同的Notifier。UserService一行都不用改。这就是开闭原则：对扩展开放，对修改关闭。

代码没有变多，反而变得更清晰。设计不是加代码，而是把代码放到正确的位置。

四、写代码前，先问五个问题

1. 谁依赖谁？ 依赖方向是否指向更稳定的抽象？
2. 变的是什么？ 把变化点找出来，单独封装。
3. 能不能不写？ 这个功能现在真的需要吗？YAGNI。
4. 好不好测？ 能不能不启动数据库就测业务逻辑？
5. 新人看得懂吗？ 设计是给人看的，顺便给机器执行。

五、常见坑

第一，过度设计。为了“以后可能扩展”而加三层抽象，结果永远没扩展。 第二，模式崇拜。把所有设计模式都塞进项目，代码反而更难懂。 第三，只画图不写代码。设计文档再漂亮，跑不起来就是空谈。 第四，忽视命名。类名、方法名就是设计的说明书，命名混乱等于设计混乱。

六、结语

软件设计，不是让你写更多代码，而是让你写更少但更准的代码。十行策略模式，胜过一百行if-else。真正的设计能力，是在变化来临时，你只需要改一处，而不是满城风雨。

记住：好的设计，让改动像换电池，而不是拆发动机。 代码可以只有十行，但背后的思考，值得你花十分钟。