Java图书管理系统核心是用class、继承、多态、封装将“书”“读者”“借阅”映射为对象模型:Book字段私有、校验逻辑内聚;BorrowRecord组合Book与Reader;LibrarySystem用Map实现O(1)查找并封装业务;查不到书抛BookNotFoundException而非返回null。

Java 中实现图书管理系统,核心不是堆功能,而是验证你能否用 class、inheritance、polymorphism 和 encapsulation 把“书”“读者”“借阅行为”这些现实概念稳稳地映射到对象模型里。写一堆 Scanner 输入和 System.out.println 输出不难,难的是结构松而不散、扩展不改主干。
图书类设计:别把所有字段都 public
常见错误是定义 Book 时直接用 public String title;,结果后续加借阅状态校验、ISBN 格式检查时处处要补漏。
正确做法是:
• 所有字段声明为 private
• 用 public 的 getter / setter 控制访问,比如 setIsbn(String isbn) 内部校验是否符合 \\d{13} 或 \\d{10}
• 借阅状态(如 available)不应靠外部直接赋值,而应通过 borrow() / returnBook() 方法变更,并同步更新库存计数
• 避免在 Book 里塞数据库连接或 UI 逻辑——它只管“它自己是什么、能做什么”
借阅记录用组合而非继承
新手常误以为 BorrowRecord 是 Book 的子类,或者反过来。这是概念混淆。BorrowRecord 和 Book 是“使用”关系,不是“是一种”关系。
应该:
• 在 BorrowRecord 类中持有 private Book book; 和 private Reader reader;
• 记录时间用 LocalDateTime.now(),别用 Date(过时且线程不友好)
• 如果系统后期要支持续借,BorrowRecord 就得有 renew() 方法,而这个逻辑放在 Book 或 Reader 里都不合适
内存版主控类:用 Map 而非 List 管理图书
很多作业用 List 存所有书,查书靠遍历 for (Book b : books) if (b.getIsbn().equals(input)) ... ——这在 100 本书时还能忍,2000 本就明显卡顿。
更合理的主控类(比如叫 LibrarySystem)应:
• 用 Map,以 isbn 为 key,O(1) 查找
• 同样用 Map 管理读者,key 可选学号或身份证号
• 所有增删改查方法都封装在该类中,避免 main 方法里散落业务逻辑
• 不在主控类里 new Scanner;输入应由单独的 InputHandler 类处理,便于后期替换成 GUI 或 Web 接口
public class LibrarySystem {
private final Map bookMap = new HashMap<>();
private final Map readerMap = new HashMap<>();
public void addBook(Book book) {
if (book != null && !book.getIsbn().trim().isEmpty()) {
bookMap.put(book.getIsbn(), book);
}
}
public Book findBookByIsbn(String isbn) {
return bookMap.get(isbn); // 直接取,无循环
}
}
运行时异常比返回 null 更能暴露问题
比如 findBookByIsbn("9780123456789") 返回 null,调用方若忘了判空,后面 book.getTitle() 就抛 NullPointerException,但堆栈指向的是调用处,不是查找逻辑本身。
更清晰的做法:
• 查不到时抛自定义异常,如 throw new BookNotFoundException("ISBN not found: " + isbn);
• 异常类继承 RuntimeException,不用强制 try-catch,但语义明确
• 这样调试时一眼看出是“找不到书”,而不是“某个对象突然变 null”
• 同理,借书前检查库存、读者是否已借满,都该提前抛异常,而不是让操作静默失败
立即学习“Java免费学习笔记(深入)”;
真正卡住人的地方,往往不是不会写for 循环,而是没想清楚“谁该知道什么”“谁该负责什么”。一个 Book 实例不该知道自己被存在哪张表里,也不该管借阅历史怎么分页显示——它只回答“我叫什么”“我还有几本可借”。其余的,交给边界清晰的协作对象。










