Hotel Management System 低层设计实战：从需求分析到多语言并发实现（awesome-low-level-design）

• 示例工程

本文以 awesome-low-level-design 仓库中酒店管理系统（Hotel Management System）的设计文档为核心，完整讲解该系统在面试场景下的需求拆解、类/接口/枚举建模，并结合仓库内 C#、Go、C++、Java 的多语言实现源码，剖析其并发控制、支付多态与单例架构的落地方式。读完本文，你将掌握一套可复用的"预订—入住—退房—支付"领域模型设计方法，并能在任意面向对象语言中独立实现一个并发安全的酒店管理系统。

需求分析：把模糊业务翻译成可设计的边界

关联文档 给出的需求清单共 8 条，是本题（与 problems/hotel-management-system.md 同源）的设计起点。逐条拆解可以得到四个核心业务域：

1. 预订与入住/退房主流程：系统需要支持客人预订房间、办理入住（check-in）与退房（check-out），这是整个系统的主干用例；
2. 房型与状态管理：需要管理多种房型（single、double、deluxe、suite），并维护房间的可用性（availability）与预订状态（reservation status）；
3. 人员与账务管理：酒店员工需要维护客人信息（guest information）、房间分配（room assignments）与账单（billing）；
4. 支付能力：支持多种支付方式，如现金（cash）、信用卡（credit card）与在线支付（online payment）。

剩下两条是典型的非功能性需求，同样是 LLD 面试的加分点：需求 6 要求"处理并发预订并保证数据一致性"（handle concurrent bookings and ensure data consistency），需求 7/8 要求可扩展、可承载大量房间与客人。它们分别对应到本文后续要讲的两类设计决策——锁与并发容器、单例与可扩展分层架构。

从仓库实现看，这一需求模型被多语言版本一致采纳：Go 版在 types.go 中用三个枚举精确复刻了房型、房间状态与预订状态；C# 版在 HotelManagementSystem.cs 中把"并发一致性"落到了ConcurrentDictionary与lock上；Java 版则在 solutions/java/src/hotelmanagementsystem 目录下通过factory、state、observer、specification等子包体现了"可扩展"的架构取向。

核心模型：类、接口与枚举的职责划分

设计文档给出了 9 个核心建模元素，它们构成了完整且自洽的领域模型：

1. Guest（客人）：持有 ID、姓名、邮箱、电话等属性，是预订与账单的主体；
2. Room（房间）：持有 ID、房型、价格、状态等属性，并提供book、check-in、check-out方法——房间自身管理自己的生命周期状态；
3. RoomType（枚举）：描述可用房型。Go 实现中依次为RoomTypeSingle、RoomTypeDouble、RoomTypeDeluxe、RoomTypeSuite，从iota开始编号；
4. RoomStatus（枚举）：表示房间状态，取值为 available（可用）、booked（已预订）、occupied（已入住）三态；
5. Reservation（预订）：表示"某客人 × 某房间 × 某日期区间"的预订记录，持有 ID、guest、room、入住日期、退房日期与状态，并提供cancel方法；
6. ReservationStatus（枚举）：表示预订状态，取值为 confirmed（已确认）或 cancelled（已取消）；
7. Payment（接口）：定义支付处理契约，由CashPayment、CreditCardPayment等具体类实现——这是教科书式的"面向接口编程"；
8. HotelManagementSystem（门面/单例）：系统的中枢组件，采用 Singleton 模式保证全局唯一实例，对外提供 add guests、add rooms、book rooms、cancel reservations、check-in、check-out、process payments 等能力，并通过同步机制处理共享资源的并发访问；
9. HotelManagementSystemDemo：演示类，串起"创建客人 → 创建房间 → 预订 → 入住 → 退房 → 取消预订"的完整使用链路。

这里有一个值得注意的建模原则：房间状态（RoomStatus）与预订状态（ReservationStatus）是两套独立的枚举，不能混用。房间关心的是"物理上能否被占用"，预订关心的是"这笔订单是否有效"，二者通过Reservation中的room引用和HotelManagementSystem的流程编排联动。Go 的 types.go 将这两组枚举分开定义，正是对这一设计决策的忠实落地。

支付的多态设计：以 Payment 接口统一多种支付方式

需求 5 要求支持现金、信用卡、在线支付等多种方式，这在 LLD 中几乎必然会落到策略模式/接口多态上。设计文档明确Payment是接口，CashPayment与CreditCardPayment是其具体实现；仓库中 C# 目录（solutions/csharp/hotelmanagementsystem）下的CashPayment.cs、CreditCardPayment.cs、Payment.cs与 Java 目录下的 payment 子包 都保持了同样的结构。

这种设计的直接收益体现在退房结算环节。以 C# 的 HotelManagementSystem.cs 为例，CheckOut方法接受的是Payment抽象类型而非具体支付类：

public void CheckOut(string reservationId, Payment payment) { lock (this) { if (_reservations.TryGetValue(reservationId, out var reservation) && reservation.Status == ReservationStatus.CONFIRMED) { var room = reservation.Room; var amount = room.Price * (reservation.CheckOutDate - reservation.CheckInDate).TotalDays; if (payment.ProcessPayment(amount)) { room.CheckOut(); _reservations.TryRemove(reservationId, out _); } else { throw new InvalidOperationException("Payment failed."); } } ... } }

从这段源码可以读出三个实现细节：计费公式为"房单价 × 入住天数"（Price × (CheckOut - CheckIn).TotalDays）；支付结果决定流程走向——只有ProcessPayment返回成功才会触发房间退房并移除预订记录，失败则抛出异常；调用方可以在运行时自由传入任意 Payment 实现，后续新增在线支付（online payment）只需增加一个OnlinePayment类即可，无需改动CheckOut逻辑。这就是"面向接口编程"在真实代码中的价值。

并发与数据一致性：锁与并发容器的落地

需求 6 是本题最容易与普通"CRUD 作业"拉开差距的地方。设计文档指出HotelManagementSystem使用同步机制处理共享资源并发访问，仓库的多语言实现给出了三种典型落地方式：

C# 版（HotelManagementSystem.cs）采用"并发容器 + 细粒度锁"组合：

• 三个共享集合_guests、_rooms、_reservations均为ConcurrentDictionary<string, T>，以 ID 为键，天然支持并发读写；
• 单例通过私有构造函数 + 静态Instance属性实现（if (_instance == null) _instance = new HotelManagementSystem();）；
• BookRoom对具体房间对象加锁（lock (room)），先检查room.Status == RoomStatus.AVAILABLE再执行预订，保证"查状态—改状态"的原子性，避免两个客人同时订到同一间房；
• CheckIn、CheckOut、CancelReservation则对系统实例加锁（lock (this)），并校验ReservationStatus.CONFIRMED前置条件，校验失败时抛出InvalidOperationException。

这种"锁对象越具体、并发度越高"的思路值得在面试中展开：对房间加锁允许不同房间的预订并行进行，而对整个系统加锁则退化为串行，是并发正确性与吞吐量之间的经典取舍。

Go 版同样面临并发问题，其 types.go 负责定义状态枚举，配合 hotel_management.go 中的领域逻辑共同构成服务层，是理解 Go 版并发控制的入口文件。Go 的常规做法是使用sync.Mutex保护共享状态，面试时可以在 C# 版对比之下顺势讨论两种语言在并发原语上的差异。

多语言实现对照：同一模型的四种表达

仓库为该问题提供了 Python、Java、C++、C#、Go 五条实现路径（各版本 README 内容保持一致，见 solutions/cpp/hotelmanagementsystem/README.md、solutions/csharp/hotelmanagementsystem/README.md、solutions/golang/hotelmanagementsystem/README.md），非常适合横向对照学习：

• C#：ConcurrentDictionary+lock处理并发，HotelManagementSystem.Instance单例，文件结构为Guest.cs、Room.cs、Reservation.cs、Payment.cs、RoomType.cs、RoomStatus.cs、ReservationStatus.cs加两个系统类；
• Go：types.go 集中定义RoomType、RoomStatus、ReservationStatus三个基于int的枚举（iota起始），room.go、reservation.go、guest.go、payment.go各自成文件，hotel_management_demo.go承担演示入口；
• C++：以Booking.hpp/cpp、Guest.hpp/cpp、Room.hpp/cpp、HotelManager.hpp/cpp组织，命名上把 Reservation 称作 Booking，门面类为HotelManager；
• Java：最完整的工程化版本（solutions/java/src/hotelmanagementsystem），不仅实现了基础模型（model包中的Guest、Room、Booking），还额外引入了decorator（房型附加服务）、factory（RoomFactory创建房间）、state（AvailableState/OccupiedState/MaintenanceState房间状态机）、observer（EmailNotifier/SmsNotifier通知）、specification（RoomAvailableSpecification等预订条件组合）五个设计模式包，并配以BookingService、RoomService、PaymentService、HotelManagerFacade的分层服务架构；
• Python：当前 solutions/python/hotelmanagementsystem 目录只包含设计文档 README（即本文主体所依据的 README.md），暂未提供.py实现文件——读者可先对照本文的类模型，再参考 C#/Go 版将其改写为 Python 的dataclass+ 单例 + 多态支付实现，是很好的编码练习。

另外，problems/hotel-management-system.md 中提供了该系统的 UML 类图，图中完整呈现了HotelManagementSystem、Guest、Room、Reservation及各枚举、支付实现之间的关联关系，适合在设计阶段先构图、再编码。

演示流程：一个完整的业务闭环

HotelManagementSystemDemo的职责是串起全部主流程。参照 Java 版 README 的示例用法，标准调用序列如下：

HotelManagementSystem system = new HotelManagementSystem(); // 添加房间 Room room = system.addRoom("101", RoomType.DELUXE, 150.0); // 创建客人 Guest guest = new Guest("John Doe", "john@example.com", "1234567890"); // 预订 Reservation reservation = system.makeReservation(guest, room, checkInDate, checkOutDate); // 入住 system.checkIn(reservation); // 退房（携带支付对象，走 Payment 多态） system.checkOut(reservation);

对照 C# 源码，这个流程的每一步都有对应的状态迁移与并发保护：BookRoom在锁内将房间从AVAILABLE置为BOOKED并生成预订 ID（C# 实现为"RES" + Guid.NewGuid().ToString("N").Substring(0, 8).ToUpper()，即RES前缀加 8 位大写十六进制）；CheckIn要求预订状态为CONFIRMED才将房间置为OCCUPIED；CheckOut则在支付成功后释放房间并移除预订。流程边界清晰、状态流转可追踪，这正是面试官期待的"可运行、可验证"的设计。

扩展方向：从 MVP 走向生产级系统

Java 版 README 给出了六条典型的演进路线，可作为 LLD 面试"如何扩展"环节的素材：

• 房间服务（room service）：记录服务请求与配送；
• 客房保洁（housekeeping）：管理保洁排班与任务；
• 会员积分（loyalty program）：实现客人积分与奖励；
• 库存管理（inventory management）：跟踪酒店物资与备品；
• 报表系统（reporting）：生成入住率与营收报表（呼应需求 7 的分析功能）；
• 通知系统（notification）：发送预订确认与提醒——Java 版已内置observer包作为该能力的基础。

这些扩展大多可以挂到既有的HotelManagementSystem门面上新增服务类，或以设计模式包的形式（Java 版的做法）增量引入，不会破坏核心预订链路——这也是"门面 + 领域模型"架构可扩展性的直接体现。

小结

酒店管理系统是一道覆盖全面、难度适中的经典 LLD 题目：需求层面横跨预订、状态机、支付、并发四大主题；设计层面涉及枚举建模、接口多态、单例与锁；实现层面则可以横跨 Java、C#、C++、Go、Python 多种语言对比学习。以 solutions/python/hotelmanagementsystem/README.md 的 9 元素类模型为骨架，结合 C# 版的并发细节、Go 版的枚举定义、Java 版的设计模式扩展，你完全可以拼装出一套既能在面试中讲清原理、又能在任何语言中亲手实现的完整方案。

• 示例工程