这类“面向对象设计题”系列我见过很多网上资料满天飞但能真正讲清楚“为什么要这样设计”的真不多。很多初学者拿到题目第一反应是赶紧写类、写方法结果写完一运行功能倒是跑通了面试官一问设计理由就卡壳。今天借这套“Java 面向对象设计题2”的复盘机会聊一聊我在练手时总结出来的一套完整思路从需求拆解、类结构设计到集合操作、深拷贝、数据一致性这些核心点全部过一遍。无论你是刚学Java的在校生还是准备校招面试的候选人只要能把这种题吃透后面写真实项目时的代码质量能上一个台阶。我这里用经典的图书馆借阅管理系统作为载体来展开。选它是因为这套题覆盖面特别全实体类设计、继承多态、接口抽象、集合排序、字符串拼接、对象拷贝、状态一致性一个场景全都能串起来。你练透这一道基本等于把Java面向对象的中高频考点都摸了一遍。1. 拿到题目先别急着写代码把需求拆成名词和动词1.1 一道面向对象设计题到底在考什么我见过太多人把这类题当成“背语法”来准备觉得能写出几个类、调通几个方法就完事了。实际上面试官和出题人真正想看的是三件事第一你能不能把现实世界的业务关系抽象成类与类之间的结构第二面对可能变化的需求你的设计有没有预留扩展空间第三落到代码层面集合、异常、字符串处理这些基本功是不是真的扎实。拿图书馆系统来说一套完整的考察点通常包括这几个维度考察维度具体体现出题人想看到的封装字段私有化、通过方法修改状态你懂不懂保护内部数据继承图书、杂志、电子资源抽象出公共父类你懂不懂消除重复代码多态用父类引用接收不同子类对象你懂不懂面向接口编程集合框架列表存取、排序、筛选、去重你的CRUD基本功是否熟练字符串处理列表展示、格式化输出你知不知道StringBuilder这种细节对象拷贝复制图书信息而不污染原对象你知不知道浅拷贝和深拷贝的区别数据一致性借书、还书的状态流转不冲突你有没有事务和并发意识注意看这些点没有一个是靠死记硬背能拿下的全部需要你在设计代码的过程中自然流露出来。所以做题的思路比代码本身更重要。1.2 名词变类、动词变方法的落地套路拿到设计题我的固定做法是先做一轮需求拆解把题目中出现的名词和动词分别列出来。这个动作看着简单却能帮你避开“想到哪里写到哪里”的混乱状态。名词部分比如图书、学生、借阅记录、图书馆这些直接对应类。动词部分比如借书、还书、查询、统计这些对应方法。拆完之后你会发现类与类之间的关系也顺带清楚了图书和学生之间是关联关系借阅记录是连接两者的中间实体图书馆则是管理所有操作的门面类。举个实际分析例子。需求里如果说“学生最多借5本书教师最多借10本”这句话听起来只是规则描述但拆解后你就知道借阅规则本身要作为一个可替换的策略存在而不是写死在学生类里。再比如说“按借阅次数对图书降序排列”这里面藏着两个需求点一是每本书需要维护一个借阅次数字段二是排序逻辑要支持动态规则。这些细节如果在写代码前就想清楚后面每个类写起来都非常快。我在练习的时候还会顺手画一个简单的关系草图不要求规范只要自己看得懂。哪个类继承哪个类、哪个类持有哪个类的集合、哪个接口被谁实现一张图画完整个项目的骨架就定下来了。之后写代码其实就是照着草图填肉。2. 类的骨架怎么搭抽象类、接口和实体类的边界2.1 为什么需要一个抽象层而不是把所有字段堆进一个类新手最容易犯的错是把所有属性塞进一个上帝类。比如题目要求管理图书就把图书编号、作者、出版社、学生姓名、借书时间全部放进一个Book类里。运行一时爽后期改需求的时候你就会发现这个类又胖又乱改一个字段要扫全文件加一种新资源类型更是牵一发而动全身。正确的思路是找出共性往上抽象。图书、杂志、电子资源它们的共同点是什么有编号、有标题、有状态可借/已借出/下架。这些共性字段和行为就应该上提到一个抽象父类比如叫LibraryResource。子类负责自己的特有字段和特有行为比如杂志有期号电子资源有文件大小。这种设计带来的最大好处是以后系统要增加DVD、有声书只要继承LibraryResource并补自己独有的东西就行原代码一行都不用动。接口在这里同样重要。不是所有资源都能被借走比如某些仅供馆内阅览的资料就不能外借。如果父类里定义借书方法就会逼着所有子类都实现一个自己用不上的行为。这时候定义一个Borrowable接口只有能外借的类才去实现它语义就非常清晰。代码里凡是处理借阅的地方只需要面向Borrowable接口编程传进来任何实现了它的子类对象都能顺利走完借阅流程。这就是面向对象的魅力所在抽象不是用来炫技的而是用来消除重复、隔离变化、让代码能够低成本扩展的。2.2 图书、学生、借阅记录三个实体类的字段设计逻辑实体类字段怎么定是一个特别值得较真的点。我见过很多解答字段拍脑袋写用的时候发现少这少那又来来回回补代码改得很痛苦。以我这边的经验三个核心实体类的字段设计可以这样拆。Book类基础字段是编号、书名、作者、分类这个不用多说。我要强调的是两个容易被忽略的字段借出状态和借阅次数。借出状态用布尔值表示是否在馆即可但借阅次数一定得单独维护因为后面做“最受欢迎图书热门分类排行”这些统计需求时直接读这个字段就能出结果不需要扫描所有借阅记录再逐条累加。这就是典型的“用空间换时间”的建模思维。Student类的字段除了学生编号、姓名、院系还需要维护一个当前借阅列表。这个列表用集合类型来存因为借还导致数量动态变化数组根本顶不住。这里还有一个隐藏细节学生能够借几本书这个上限建议放在一个配置字段或规则类里不要硬编码在方法里。后面想调整规则改一处就行不用去翻业务代码。BorrowRecord类连接图书和学生记录编号、图书编号、学生编号、借出时间、应还时间、实际还书时间。这类时间字段一定要用LocalDate或LocalDateTime不要用String存。原因很简单LocalDate支持时间计算判断是否逾期、计算借了多少天都是现成的API方法String存的时间只能看不能算后期做任何统计都得先解析平白无故引入一堆麻烦。2.3 用集合还是数组容器选型背后的理由实体类里存一组对象到底用数组、ArrayList还是别的集合这问题看起来基础但真能反应一个人有没有实际项目经验。数组的长度固定初始化之后没法增删元素存借阅列表这种动态变化的数据就是给自己挖坑。LinkedList在中间频繁插入删除时有理论优势但实际业务里这种操作少而且随机访问性能差日常开发中用得远不如ArrayList多。所以默认情况下列表用ArrayList就够了。可如果你需要保证图书集合中书名不重复并且希望遍历时自动按某种顺序输出那可以考虑HashSet或TreeSet配合重写equals和hashCode方法既能去重又能排序。什么时候用Map也值得想清楚比如要通过编号快速找到图书对象HashMap的O(1)查询效率就远胜于遍历List。容器选型不是背API而是根据数据特征和访问模式来选最合适的工具。3. 借书还书这样写才能把语法变成能力3.1 核心方法的状态流转与数据一致性控制借书还书是整个系统的心脏也是检验数据一致性的关键场景。如果你只在Book里把状态改成已借出却没有同步更新Student的借阅列表就会出现学生列表里查不到这本书、书的状态却是已借出的诡异情况。更严重的问题是并发两个方法同时操作同一个Book对象互相读到旧状态就会出现“同一本书被借出去两次”的事故。解决思路分三层。第一层是把所有状态变更操作收口到LibraryManager这个门面类中外部代码不能直接拿着Book对象去改状态所有借还动作都必须调用LibraryManager的borrowBook和returnBook方法。这是封装性带来的约束力也是保证一致性的第一道防线。第二层是在方法内部做完整的业务校验图书是否存在、学生是否存在、书是否已借出、学生是否达到借阅上限任何一项不满足就直接拒绝。第三层是把操作包在同步机制里让方法级别具备线程安全能力。核心逻辑可以这样组织public synchronized boolean borrowBook(String bookId, String studentId) { Book book findBook(bookId); Student student findStudent(studentId); if (book null || student null) { return false; } if (book.isBorrowed()) { return false; } if (student.getBorrowedBooks().size() student.getMaxBorrowLimit()) { return false; } book.setBorrowed(true); book.increaseBorrowCount(); student.getBorrowedBooks().add(book); BorrowRecord record new BorrowRecord(bookId, studentId); records.add(record); return true; }注意这段代码里的两个细节一是book.increaseBorrowCount()跟着借出动作一起执行保证借阅次数永远和借出行为保持一致二是借阅记录在状态全部更新成功后才创建顺序不能反过来。如果后面真要接数据库这套思路还可以平滑过渡到事务控制先把对象层面的状态原子性做好后面什么都不慌。3.2 深拷贝对象复制掉过的坑和正解题目做深了早晚会碰到对象复制的问题。典型场景是管理员想基于某本馆藏图书创建一个推荐版本把推荐理由加上去但不希望改动原图书记录。新手上来就写Book copy originalBook看起来是复制实际上originalBook和copy指向的是同一个对象改任何一边两边都跟着变。这就是引用赋值和对象拷贝的最本质区别。Java默认的clone方法是浅拷贝基本类型字段会复制一份但引用类型字段复制的是地址引用。也就是说如果Book内部有一个List 或作者对象浅拷贝出来的新对象和原对象共享同一份引用数据修改新的列表老的列表也变。所以做深拷贝要么手动新建对象并逐字段复制可变引用类型的内容要么实现Serializable后用序列化方式整体复制。手动实现深拷贝的代码其实不复杂关键是要有意识地把集合类字段也重新创建public Book deepCopy() { Book copy new Book(this.title, this.author); copy.setBookId(this.bookId); copy.setCategory(this.category); copy.setBorrowed(this.isBorrowed); copy.setBorrowCount(this.borrowCount); copy.setTags(new ArrayList(this.tags)); return copy; }这里特别提醒一下new ArrayList(this.tags)只是复制了列表结构如果tags里的元素本身也是可变对象还得逐个再拷贝一层。到底复制到哪一层取决于业务上允许多深的改动不用盲目追求无限深拷贝够用就好。3.3 字符串拼接用StringBuilder别等卡顿才后悔输出馆藏图书列表的时候需要把大量图书信息拼成一段展示文本。新手最自然的写法是用加号拼接比如result book.getTitle() \n。数据量小的时候这种写法没有任何感知问题可一旦列表里有几千本书每次用加号拼接都会在底层创建一个新的StringBuilder和新的String对象循环下来会制造大量中间垃圾对象触发频繁的GC。我帮人做过代码评审见过一次真实案例几千条数据拼展示信息页面卡了两三秒罪魁祸首就是循环里的字符串加号拼接。正确做法是循环外部创建StringBuilder循环内部用append追加内容StringBuilder sb new StringBuilder(); for (Book book : books) { sb.append(book.getTitle()) .append( | ) .append(book.getAuthor()) .append(System.lineSeparator()); } String displayText sb.toString();注意append方法返回的是当前StringBuilder对象本身所以可以链式调用这是它设计上的一个特性写起来也简洁。StringBuilder是线程不安全的单线程场景用它是性能最优解如果多线程并发拼接才需要改用StringBuffer但实际业务里这种并发场景很少默认用StringBuilder就行。4. 排序、统计与查询集合操作的实战用法4.1 Comparable和Comparator怎么选统计热门图书、按分类查询、展示时按书名排序这些需求在图书馆系统里非常常见也正好对应Java排序机制的两个核心接口。刚开始学的时候很多人分不清Comparable和Comparator其实两者定位完全不同。Comparable是“类自己定义默认排序规则”比如Book类实现Comparable接口并重写compareTo方法规定按书名升序排列。这样直接调用Collections.sort(books)就能生效排序规则天然跟随Book类走。Comparator则是“外部单独定义排序规则”适合处理那些不属于类本身的临时需求。比如“按借阅次数从高到低排”“按价格排序”这些规则没有必要写进Book类里用Comparator更干净。Java 8之后写法非常简洁books.sort(Comparator.comparingInt(Book::getBorrowCount).reversed());这行代码的意思是用借阅次数作为比较基准然后反向排序。方法引用Book::getBorrowCount代替了冗长的匿名内部类可读性提升很多。原则很简单默认排序用Comparable多种临场排序用Comparator两种配合起来基本能应对所有排序场景。4.2 借阅排名与分类统计的两种实现方式统计哪本书最受欢迎最直接的办法是遍历图书列表按借阅次数排序取前N名。前面把借阅次数维护在Book字段里的好处在这里完全体现出来排序语句一行搞定不用去关联查询借阅记录。分类统计则稍微绕一点需要按图书分类分组然后统计每个分类下有多少本书。这里可以用一个MapString, Integer来存储分类名和对应的数量遍历的时候逐个累加。也可以用Stream的分组统计功能MapString, Long categoryCount books.stream() .collect(Collectors.groupingBy(Book::getCategory, Collectors.counting()));两种写法最后结果一样但Stream方案的代码量明显更少。不过Stream不是万能的数据量特别大或者需要中途打断的时候传统循环配合Map依然更直观。建议把两种方式都写一遍理解它们的差异面试时不管被问到哪种都能从容展开。5. 常见异常与排查笔记新手最容易踩的四个坑5.1 构造器链断掉导致的编译失败写继承关系的时候子类构造器第一行默认会调用父类的无参构造器super()。如果父类只定义了有参构造器而没写无参构造器子类编译直接报错。这个错误看似简单实际排查起来可能浪费好几分钟因为编译器提示语对于新手来说并不直观。解决办法有两个方向一是父类显式提供无参构造器哪怕里面什么都不做二是子类构造器里显式调用父类的有参构造器把公共字段的初始化责任交给父类。我推荐第二种做法因为父类有必填字段时强制子类给出这些字段的值反而让设计更健壮。5.2 不重写equals和hashCode集合行为全乱套把Book放进HashSet或者作为HashMap的key如果没有重写equals和hashCode两个内容完全相同的Book对象会被当成不同的元素。表现出来就是去重失效、Map取值取不到、集合大小异常。规范做法是重写这两个方法而且要遵循约定equals相等的两个对象hashCode必须相等。我通常只基于业务唯一标识字段来比较比如bookIdOverride public boolean equals(Object o) { if (this o) return true; if (!(o instanceof Book)) return false; Book book (Book) o; return Objects.equals(bookId, book.bookId); } Override public int hashCode() { return Objects.hash(bookId); }注意Objects工具类的使用它帮我们处理了空指针判断代码也简洁。如果你用了IDEA等主流开发工具生成这两个方法的功能非常成熟但一定要理解背后的原理否则生成完改字段时很容易漏同步。5.3 遍历时删除元素引发的ConcurrentModificationException遍历List的过程中直接调用list.remove删除元素几乎必定抛出ConcurrentModificationException。原因在于ArrayList的迭代器会维护一个期望修改次数而列表自身的结构性修改会改变实际修改次数两者对不上就立刻抛异常。推荐用迭代器的remove方法或者Java 8之后的removeIfbooks.removeIf(book - book.getBorrowCount() 0);这句话的含义是删除所有借阅次数为零的图书一行搞定既安全又可读。如果在遍历过程中还要做其他操作最稳妥的办法是先收集要删除的对象到临时集合遍历结束后统一批量移除。5.4 测试数据污染演示结果的“社死”现场练手时为了方便调试很多人直接在main方法里new了一堆测试图书、测试学生功能调通后也懒得清理。提交作业或者面试演示时打开列表一看满屏都是“测试图书A”“张三同学1号”观感极其业余。正确做法是把测试数据集中封装在一个MockData类里专门负责生成演示数据集。提交或演示前只需要去掉调用MockData的入口系统就能以一个干净的状态运行。这个过程对代码结构没有任何侵入却能让你的演示效果专业很多。6. 这个题还能怎么改从练手题到设计模式实战6.1 借阅规则变化时用策略模式替代if-else原题如果再往前一步把“学生限借5本、教师限借10本”这种规则纳入系统很多人的第一反应是在borrowBook方法里写if判断。这种写法在规则少的时候没问题可规则一旦增加比如“研究生限借8本”“校友限借3本”方法会越来越长每次改动都要动核心代码风险极高。策略模式就是针对这类问题的标准答案。定义BorrowRule接口统一提供getMaxBorrowLimit方法学生、教师、研究生各自实现自己的规则类LibraryManager只依赖BorrowRule接口具体用哪条规则在调用时传入即可。新增规则不需要修改管理类只需要新增一个规则实现类这就是开闭原则的直观体现。6.2 单例模式管理图书馆入口防止多个实例状态分裂整个图书馆系统只需要一个LibraryManager实例如果main方法里不小心new了两次就可能出现两个管理器各自维护一套图书数据借书记录互相不认识的混乱状态。这种场景天然适合单例模式。推荐用枚举单例代码最简洁且天然线程安全public enum LibraryManager { INSTANCE; private final ListBook books new ArrayList(); public boolean borrowBook(String bookId, String studentId) { // 借书逻辑 return true; } }调用侧统一使用LibraryManager.INSTANCE所有状态都集中在这一个实例里不再需要担心多个副本带来的数据分裂问题。做这类设计题我个人最大的体会是写代码只是最后一步真正拉开差距的是建模和权衡的过程。同样一个借书系统有人能写出一百行的上帝类有人能搭出扩展性良好的层次结构差别就在动手前的思考深度。如果你手头正好在做类似的面向对象练习题强烈建议按我上面这套流程走一遍从拆解需求开始到设计结构最后再落到代码。做完之后还可以试着把题目改一改比如加上逾期罚金计算、图书预约功能你会发现最初设计里的很多薄弱环节一下子就暴露出来了这个过程比多做十道题都管用。
