低层设计 LLD 实用指南：5 步走完一次类设计，附自查清单-开发者社区

低层设计 LLD 实用指南：5 步走完一次类设计，附自查清单

【免费下载链接】The-Complete-FAANG-PreparationDive into this repository, a comprehensive resource covering Data Structures, Algorithms, 450 DSA by Love Babbar, Striver DSA sheet, Apna College DSA Sheet, and FAANG Questions! 🚀 That's not all! We've got Technical Subjects like Operating Systems, DBMS, SQL, Computer Networks, and Object-Oriented Programming, all waiting for you.项目地址: https://gitcode.com/gh_mirrors/th/The-Complete-FAANG-Preparation

面试白板上的低层设计（LLD）拼的不是背概念，而是 20 分钟内把一句话需求落成能讲清楚的类图。跟着 The-Complete-FAANG-Preparation 仓库里的 OOP 资料走一遍本文流程，你能独立走完一次完整的 LLD 设计，并学会对着清单自查。

面试官看 LLD 时，真正在看什么

别急着画框。面试官落下的前 10 分钟里，心里只有三个标尺：

职责划分：每个类是不是只管一件事？你一口气写出一个又发号、又喊号、又算费、还管界面的Manager，基本就凉了。
对象交互：能不能用嘴把"用户点按钮之后，哪个对象调了哪个方法"讲清楚？讲不出调用顺序，类图只是好看的框图。
扩展性：加一句"现在要支持 VIP 通道"，哪些类要动、哪些完全不用碰？改得动的地方越少，分得越对。

记住这三条，后面五步每一步都在为它服务。

五步法拆解一次 LLD 设计

这套清单可以贴在白板角落，每次设计前过一遍：

澄清需求：先追问边界，别急着写类。这一步的价值是把隐藏假设摊到台面上，省得设计到一半推翻重来。
定义接口：只站在使用者视角，说系统"能做什么"，不讨论内部怎么实现。接口定死了，后面拆类才有验收标准。
拆类与定关系：按"谁管理谁的状态、谁调用谁"分家，标清组合还是依赖。类之间留白，改一处不牵全身。
处理边界与异常：空队列、并发冲突、非法状态转换，逐个指定"谁报错、返回什么"。边界处理是区分及格和优秀的分界线。
走查自测：用 3 句话讲一遍正常流程，再补 3 句异常流程，卡壳的地方就是漏洞。这一步不能省。

前四步决定画面对不对，第五步决定你敢不敢讲出来。

案例：把门诊叫号系统落成类图

需求一句话："给门诊做个叫号系统：分科室发号，医生按序喊号，病人可以过号重排，大屏展示当前队列。"

第一步，澄清需求。问出边界再动手：叫号到第几位？过号是排到队尾还是直接作废？是否需要取消工单？——这些答案直接决定后面要哪些状态。

第二步，定义接口。站在病人、医生、大屏三个角色的视角，系统只需要五个动作：挂号发号、喊下一个、过号重排、取消、查看队列。到这一步还没出现任何类名。

第三步，拆类与关系。一个工单Ticket管自己的状态流转；Clinic负责按科室发号；DoctorWindow执行喊号和过号；Board只读展示，绝不允许反向改状态；TicketCenter做调度，把其余对象串起来。注意这里全程用组合与依赖，一个继承都不必——状态归Ticket自己管，TicketCenter只负责编排。

第四步，边界与异常。工单有"待叫 / 已叫 / 已就诊 / 已取消 / 已过号"五种状态。别用布尔字段拼，拼出来的状态里混着一堆不可能出现的组合。用状态机约束转移：

// 工单状态机：只允许合法转移，拒绝其余一切请求 public enum TicketState { WAITING, CALLED, VISITED, CANCELLED, SKIPPED; public boolean canGoTo(TicketState next) { if (this == CANCELLED || this == VISITED) return false; // 终态锁死 if (this == SKIPPED) return next == WAITING; // 过号只能重排回队列 if (this == WAITING) return next == CALLED || next == CANCELLED; if (this == CALLED) return next == VISITED || next == SKIPPED; return false; } }

队列空了喊下一个、已取消的号被二次跳过，这类问题都在这张转移表里被堵死。

第五步，走查自测。正常路径：挂号 → 喊号 → 就诊 → 大屏刷新；异常路径：空队列喊号、已取消的号被跳、过号重排后再过号。每条都指定了返回值，面试时照着念就行。

这段案例里藏了两个设计模式实战的落点：状态多且转移复杂时，State 式状态机比一串 if 清晰，转移规则集中在一张表里，加状态不用翻代码；TicketCenter充当门面，其余类只面对它这一个入口——这正是 SOLID 里的开闭原则：以后换成"分诊台统一调度"，只动TicketCenter，调用方无感。模式是跟着需求长出来的，不是背出来的。

高频坑点自查清单

设计完成后，拿这七条逐条过：

有没有超过 5 个方法的上帝类？有，立刻拆。
有没有new出来的硬编码依赖？该注入的没注入，测试没法写。
入参 null、空队列、非法状态，是否都指定了"谁报错、返回什么"？
单个接口方法超过 7 个了吗？超过就该拆成两三个小接口。
状态机的每条转移都合法吗？终态还能再动吗？
每个异常路径都有明确返回值，而不是"应该没问题"？
核心流转逻辑能不能不依赖数据库单测？

七条全过，再上白板；有一条没过，先回去补刀。

低层设计 LLD 类设计白板推演练习场景. University Website Using Javascript And Bootstrap/imgs/main_class.jpg)

接下来怎么练

仓库里有现成的练习路径，按顺序走：

先补概念：2]. Technical Subjects/0]. Object Oriented Programming (OOP)/Object Oriented Programming Notes.pdf，对照着把 OOP 里封装、继承、多态、抽象各自"解决什么问题"讲给自己听。
找题源：3]. System Design/01]. Low Level Design/是 LLD 题目的目录入口，2]. Technical Subjects/Interview Questions/0). Object Oriented Programming (OOP)/放 OOP 面试题，每次挑一题，用五步法在纸上走完再核对。
动手拆：1]. DSA + CP/1]. DSA/1]. Data Structures/06]. Linked List/里的实现代码，任选两题，不看答案先用五步法拆类，再和原实现对照差异。

每练一题，回来对照上面的自查清单打勾。