设计模式：设计原则 —— 把软件当成一家“理想餐厅”来经营

可视化演示

展示SOLID五大设计原则的模块关系与耦合度评估：单一职责、开闭、里氏替换、接口隔离与依赖倒置，交互切换理解架构解耦。

原则总览：餐厅的经营哲学

一家餐厅开业前，老板不会先买锅碗瓢盆，而是先定“经营哲学”：分工明确、流程清晰、设备通用、随手能加菜。这些哲学不规定具体菜谱，却决定了餐厅能开多大、能活多久。软件系统的“经营哲学”就是设计原则——它是经验法则，不是语法规则，编译器不报警，但违反它的系统会在需求变化的重压下迅速腐坏。

设计原则的雏形来自二十世纪八十年代面向对象设计的实践总结，其中最著名的是 Robert Martin 归纳的五条 SOLID 原则，后来又补充出 DRY、KISS、YAGNI 等辅助原则。设计原则与设计模式的关系，好比“菜谱的原理”与“具体的菜谱”：模式是前人验证过的固定解法，原则是模式的灵魂。同一个原则可以由多种模式实现，比如开闭原则既能用策略模式落地，也能用装饰器模式落地。

衡量设计好坏常看两个标尺：内聚是“模块内部零件咬合紧密”，耦合是“模块之间互相牵连的松散度”。高内聚、低耦合是所有原则的共同目标——就像餐厅里甜点组内部配合默契，但甜点组与收银台之间只靠一张小票交接，互不干扰。

所以，设计原则就是餐厅的“经营哲学”：它不告诉你具体做哪道菜，而是在招聘、排班、采购时给你判断依据。有了这套哲学，餐厅才能从小店长成连锁品牌，软件才能从小模块长成大系统。

单一职责原则：一人一岗

在理想餐厅里，每个员工只有一个岗位：洗碗工绝不兼职做账，厨师绝不亲自端菜。因为“做菜”和“端菜”是两个不同的变化来源——菜式要创新，服务要提速，若由同一人承担，任何一边的变动都会连累另一边。代码世界同理：把不相关的逻辑塞进同一个类，就是让洗碗工兼做账。

单一职责原则（SRP）把这条规矩写成硬约束：一个类应该只有一个引起它变化的原因。注意，“职责”不等于“功能”——一个类可以有好几个方法，但它们必须服务于同一类“变化源”。判断方法非常简单：问一句“谁会要求修改这个类？”如果答案是财务部和市场部两个业务方，那就是两个职责，应该拆开。

实践中，一个“读配置、解析数据、存库、发通知”的多面手类，往往会在一次紧急需求里被改三次，每一次都冒着弄坏其他功能的风险。拆分的依据是“变化轴线”：把同一时间、同一原因的变化放在一起，把不同节奏、不同发起方的变化拆开。

就像餐厅让收银员专注收银、甜点师专注甜点，SRP 让每个类都有清晰的“岗位牌”。之后任何一处改动都只牵动一个岗位，其他同事照常出餐，互不添乱。

开闭原则：不砸墙也能加新菜

理想餐厅加新菜时，不会砸墙改厨房。老板只需让厨师照着“标准化菜谱格式”再写一页，挂进菜单夹即可。菜品可以无限增加，而餐具、流程、培训体系纹丝不动。这就是软件世界梦寐以求的升级方式：加功能像贴页，而不是拆墙。

开闭原则（OCP）说：软件实体应该对扩展开放，对修改封闭。意思是系统升级时，应优先通过“新增代码”来应对变化，而不是回头修改已经稳定运行的核心代码。核心做法是抽象——用接口或抽象类定义“菜谱格式”，让新需求以“新实现”的方式加入系统，而不是改动老菜谱。

常见落地手段有策略模式（替换算法）、模板方法（固定流程骨架）、装饰器（动态增强功能）。它们都把“变化的细节”挡在“稳定的骨架”之外。要注意，开闭不是绝对的“一行旧代码都不许碰”，而是把修改控制在小范围、隔离在系统边缘，让核心模块长久稳定。

菜单夹每多一页，厨房墙皮一动不动；你的代码每新增一个子类，老模块的测试用例一行不改还能全部通过。这就是开闭原则带给系统的“添菜自由”。

里氏替换原则：副主厨能顶班

主厨休假时，副主厨必须能顶上去，出品的口味、出餐的节奏不能有差别。老板不需要知道今天是谁掌勺——这就是“可替换”的信任。可替换的前提不是资历，而是行为一致：副主厨守住了主厨的全部出品标准。

里氏替换原则（LSP）由 Barbara Liskov 提出：所有引用父类的地方，必须能透明地使用其子类对象。注意，继承只给了你“父子名分”，不会自动保证行为兼容。经典反例是正方形继承长方形：长方形设置宽和高是两件独立的事，正方形却要求两者永远相等，于是 setWidth 时 setHeight 被悄悄改写，父类契约就此破裂。

满足 LSP 要做到三点：子类不能削弱父类的前置条件（如“必须非空”变成“可以为空”）、不能增强后置条件（返回值范围不许扩大）、必须保持父类的不变式（如正方形边长相等这类内部约束）。LSP 是继承正确性的“行为契约”，也是“多用组合、少用继承”背后真正的理由。

就像轮换厨师不能砸招牌，LSP 要求“换成子类，系统还像原来一样工作”。任何“为了复用代码而继承”的念头，都要先过一遍替换测试：把父类换成子类，世界会乱吗？

接口隔离原则：菜单分成小册子

在理想餐厅，顾客只看菜单，后厨看设备手册，财务看账本。如果每位顾客进门都要通读一整摞《餐厅运营全手册》，找一道菜会累死。所以菜单拆成前菜、主菜、甜点几本小册子，各取所需。接口亦然：每个调用方只应看到自己关心的那几页。

接口隔离原则（ISP）说：客户端不应被迫依赖它用不到的接口方法。“胖接口”就是那摞全手册——一个接口塞进 20 个方法，每个实现类都得写满 20 个方法的空壳，哪怕只用其中 3 个；一个方法签名变动，所有无关实现都被迫重新编译。

拆分的准则是“按客户端角色”而非“按功能多少”：把接口拆成多个专注的小接口，每个对应一个业务角色，比如订单接口拆成“下单者接口”和“管理员接口”。必要时再用适配器（Adapter），把一个宽接口翻译成客户端需要的窄接口。但过犹不及——接口不是越细越好，拆到每个方法一个接口，就失去了聚合的意义。

菜单被拆成三本小册子，改动甜点菜单不会让前菜菜单重新印刷；接口被拆成角色小接口，改动一个角色的方法签名，其他角色一行代码都不用动。

依赖倒置原则：标准插座

理想餐厅的电器全走标准插座取电。电饭煲要更新，拔下旧插头，插上新电器即可，墙里的电线不用重排。餐厅的“业务目标”（供电）与“具体设备”（电饭煲）之间，隔着一层谁都认识的“标准插座”——它让两边的变化互不牵连。

依赖倒置原则（DIP）说：高层模块不应该依赖低层模块，两者都应该依赖抽象；抽象不应该依赖细节，细节应该依赖抽象。没有倒置时，业务层直接 new 一个 MysqlStorage、一个 EmailSender，换数据库或换短信供应商就要改写业务层；倒置之后，业务层只认识 Storage 接口和 Sender 接口，“谁来干活”由外部决定。

落地工具是依赖注入（Dependency Injection）：把具体实现通过构造函数、setter 或工厂传入高层模块，而不是在高层模块内部 new 出来。像 Spring 这类框架只是把注入过程自动化，原则本身与框架无关——即便没有框架，手写构造函数注入同样是依赖倒置。

插座让厨房电器“即插即用”，DIP 让业务模块“即插即换”。招牌菜不变，灶台更新换代——双方都只认中间那个标准接口，这就是稳定架构的秘密。

DRY与KISS：母配方与一页纸菜单

理想餐厅的酱汁只有一个母配方，锁在总厨文件柜里，所有菜品的酱汁都从它衍生，而不是每道菜各抄一遍——抄三遍就迟早会有两份配方改得不一致。菜谱永远是一页纸能写完的简单流程，因为复杂菜谱最容易做砸。老板也不会为“可能有一天会来的贵宾”提前布置一整层包间。

DRY（Don't Repeat Yourself）要求每个知识在系统中有且只有一个权威表达；KISS（Keep It Simple, Stupid）要求以最简单可用的方式解决问题；YAGNI（You Aren't Gonna Need It）警告你不要为臆想的需求提前设计。三者从“消除重复、控制复杂度、抑制超前”三个方向守护系统健康。

关键在于理解 DRY 反对的是“知识重复”而非“文本重复”——同一业务规则同时写在数据库约束和前端校验里，即使文字不同也是重复。KISS 可以用圈复杂度度量，每多一个 if 分支，测试路径就多一条，心智负担就重一分；YAGNI 与“抽象上瘾”是相反的两种病，正确姿势是用简单方案起步，等重复和复杂度真实出现时再按原则重构。

母配方只写一份，菜谱只有一页纸，不为幻想中的客人预留包间——DRY、KISS、YAGNI 让餐厅每一分精力都花在真实的经营上，而不是维护冗余和猜测。

原则综合运用：经营是权衡的艺术

一家餐厅真正成熟，不是把每条守则都执行到极致，而是老板懂得变通：节日客流爆满时允许服务员临时传菜——短暂打破单一职责，但常态依旧分工明确。原则不是教条，是经营智慧：它们之间有张力，需要按场景调配。

SOLID 与 DRY/KISS/YAGNI 之间确实存在冲突：为了满足 ISP 拆出的细接口，可能违背 KISS 的“简单”；过度追求 DIP 的抽象层，可能撞上 YAGNI 的“你现在用不到”。成熟的工程师把原则当“体检指标”，结合具体上下文决定优先级。实践上推荐“重构三步”：先让代码可测（testable），再在变化点引入抽象，最后用设计模式固化结构。

一个真实演进过程：报表模块初期只用 SRP 把取数、计算、导出拆成三个类；当报表种类增多，用策略模式让每种报表成为子类（OCP）；各报表共享的接口由基类保证行为一致（LSP）；上层服务只依赖抽象接口（DIP）；客户端只拿自己需要的窄接口（ISP）。每一步都小步提交、测试守护。

经营餐厅的智慧，是在分工与简单、扩展与克制之间找平衡。设计原则是地图，不是锁链；用它们指导重构，而不是被它们束缚手脚。真正的高手，看的是系统的长期生命力。

AI 应用场景

Python 演示

from abc import ABC, abstractmethod  class LLMProvider(ABC):    """抽象层: 依赖倒置原则的锚点, 高层只认识这个接口"""     @abstractmethod    def chat(self, prompt: str) -> str:        pass  class OpenAIImpl(LLMProvider):    def chat(self, prompt: str) -> str:        return f"[OpenAI] 回复: {prompt}"  class WenxinImpl(LLMProvider):    def chat(self, prompt: str) -> str:        return f"[文心] 回复: {prompt}"  FACTORY: dict = {}  def register(name: str, provider: LLMProvider) -> None:    """新增供应商 = 新增一个实现类 + 一行注册, 核心代码零修改 (OCP)"""    FACTORY[name] = provider  class AIService:    """高层业务: 不依赖具体供应商, 只依赖抽象 LLMProvider"""     def __init__(self, provider: LLMProvider):        self.provider = provider     def ask(self, prompt: str) -> str:        return self.provider.chat(prompt)  if __name__ == "__main__":    register("openai", OpenAIImpl())    register("wenxin", WenxinImpl())     service = AIService(FACTORY["openai"])    print(service.ask("你好"))     service = AIService(FACTORY["wenxin"])    print(service.ask("你好"))

1. class LLMProvider(ABC):定义抽象层，高层与低层都依赖它，这是依赖倒置的锚点
2. def register(name, provider):系统唯一的扩展点，新增厂商等于新增一行注册
3. class AIService:高层业务类只认识抽象接口，不认识任何具体实现
4. self.provider = provider依赖注入：具体实现从外部传入，而不是在内部 new
5. service = AIService(FACTORY["wenxin"])运行时切换实现，行为一致可替换，体现 LSP

常见误区

面试题