Java酒店管理系统应以准确建模现实概念为核心：Room与RoomType分离，Room持RoomType引用；Booking用状态枚举封装流转；Hotel仅聚合协调，不越权处理业务逻辑与IO。
Java里实现一个简单的酒店管理系统，核心不是堆砌功能，而是把「房型、房间、客人、订单」这些现实概念准确映射成类，并让它们之间用合适的关系协作。不搞清职责边界和对象生命周期，后面加个退房逻辑都能绕晕自己。
Room 和 RoomType 必须分离，别把房型信息硬塞进 Room 实例
常见错误是把 roomType 写成字符串或枚举字段，导致无法动态调整价格、床型、最大入住人数等属性。正确做法是让 Room 持有对 RoomType 的引用：
public class Room {
private String roomNumber;
private RoomType type; // ← 关键：引用而非复制
private boolean isOccupied;
public Room(String roomNumber, RoomType type) {
this.roomNumber = roomNumber;
this.type = type; // 同一房型下所有房间共享 price、bedCount 等
}
public double getPricePerNight() {
return type.getPricePerNight(); // 逻辑集中到 RoomType
}
}
-
RoomType应包含pricePerNight、bedCount、amenities等可配置属性，支持后期按季节/活动调整 - 避免在
Room中重复存储价格——否则改一个房型的价就得遍历所有房间实例 - 如果房型需唯一标识（如用于数据库），给
RoomType加id字段，别用名称做主键
Booking 类必须封装状态流转，别用布尔字段模拟业务过程
用 isConfirmed + isCheckedIn + isCanceled 这类平行布尔字段，很快会陷入状态组合爆炸（比如 isConfirmed=false, isCheckedIn=true 是什么合法状态？）。应该用枚举驱动状态机：
public enum BookingStatus {
PENDING, CONFIRMED, CHECKED_IN, CHECKED_OUT, CANCELED
}
-
Booking类内只暴露confirm()、checkIn()、cancel()等方法，每个方法校验前置状态并更新status - 例如
checkIn()只允许从CONFIRMED转入，否则抛IllegalStateException - 取消订单时，要联动释放
Room占用状态，这个逻辑不能散落在调用处，必须封装在Booking.cancel()内部
不要让 Hotel 类变成上帝对象，它只负责聚合和协调
新手常把查房、下单、生成账单全塞进 Hotel 类，结果这个类几百行还带一堆静态工具方法。正确职责是：
立即学习“Java免费学习笔记（深入）”；
- 持有
List<Room>、List<Booking>、Map<String, RoomType>等核心集合 - 提供
findAvailableRooms(LocalDate, LocalDate)这类组合查询——但具体日期冲突判断交给Booking自己的overlapsWith(Booking other)方法 - 不处理 IO：读取初始房型数据、保存订单记录，应交给独立的
RoomRepository或BookingDao，哪怕只是内存 Map 实现 - 避免在
Hotel里写格式化输出逻辑（如打印账单），那是BookingPrinter或视图层的事
真正难的不是写完增删改查，而是当运营提出「会员订房享95折，但仅限工作日」时，你能否在不碰 Room 和 Hotel 的前提下，只改 Booking 的价格计算逻辑。面向对象设计的好坏，这时候才露出来。
