Java第五章练习题深度解析：从抄答案到独立设计

1. 从“找答案”到“拆逻辑”：第五章练习题到底在练什么

很多人搜“Java经典实战开发第五章的练习题答案”，心里想的其实是一件事：赶紧把题做完交差。但我带了这么多届新人，发现一个规律——凡是直接抄答案的，到了第六章、第七章还会回来搜，而且越搜越焦虑。原因很简单，第五章通常是一个分水岭：前面几章讲变量、循环、数组，属于“照着敲就能跑”；到了第五章，题目开始要求你把零散知识拼成一个能解决实际问题的完整逻辑，比如面向对象的封装、继承、多态，或者集合框架的增删改查，再或者异常处理与文件读写的配合。

这一章的核心价值不在于“答案对不对”，而在于“你能不能独立把需求翻译成代码结构”。我见过太多人卡在第五章，不是因为语法不会，而是因为不知道从哪下手：题目给了一段模糊描述，要求设计类、写方法、处理边界情况，这时候如果没有一套拆解方法，看答案也看不懂为什么这么写。

所以这篇内容我不打算只丢几个代码片段给你。我会把第五章常见的几类练习题拆开，讲清楚每道题背后的考察意图、我实际带人时发现的典型错误、以及从“能跑”到“写得好”之间差的那几步。适合正在学Java基础、卡在第五章练习题上、或者想回头把基础打牢的人。你不需要先看完前面所有章节，但至少要能看懂基本的类、方法、循环和条件判断。

先给一个我自己的判断：第五章练习题如果只求“输出正确”，大概能覆盖60%的考点；剩下40%藏在代码结构、命名、异常处理和边界测试里。而这些恰恰是后面做项目时天天用的东西。下面我按题型分类，一类一类拆。

2. 面向对象设计题：别急着写main，先把“谁有什么”列清楚

2.1 这类题在考什么：从“过程思维”切换到“对象思维”

第五章最常见的练习题就是“设计一个XXX系统”，比如图书管理、学生成绩管理、银行账户操作。题目通常只给一段文字描述，要求你定义类、属性、方法，然后写一个测试类跑起来。很多人上来就写public static void main，然后在里面堆一堆变量和if-else，最后也能输出正确结果，但完全没用到面向对象。

我带人时反复强调一句话：先别管代码，拿张纸把名词和动词分开。名词大概率是类或属性，动词大概率是方法。比如“学生有姓名、学号、三门课成绩，可以计算总分和平均分”，那么“学生”是类，姓名/学号/成绩是属性，计算总分和平均分是方法。这个动作看起来简单，但能帮你避开“把所有逻辑塞进main”的坑。

2.2 属性该用private还是public：一个真实踩坑案例

练习题答案里经常出现public String name;这种写法，因为短、好写、测试方便。但如果你照着抄，后面遇到“成绩不能为负数”这种要求时就傻了——因为外部可以直接改。正确做法是属性用private，通过构造方法或setter赋值，在setter里做校验。

我一般建议新手至少做到这一点：所有属性private，需要外部访问的提供getter/setter，构造方法负责初始化必要属性。这不是为了“显得专业”，而是因为第五章之后马上会讲封装，你现在按这个结构写，后面理解起来毫不费力。

public class Student { private String name; private String id; private double score; public Student(String name, String id) { this.name = name; this.id = id; } public void setScore(double score) { if (score < 0 || score > 100) { throw new IllegalArgumentException("成绩必须在0到100之间"); } this.score = score; } public double getScore() { return score; } }

这段代码比答案里常见的“全public”版本多了十几行，但它把“成绩范围校验”这个需求真正落地了。练习题如果只要求输出，你可能觉得没必要；但如果你以后要写任何真实系统，这种校验是底线。

2.3 继承和多态题：为什么答案里的父类总有一个空方法

第五章后期通常会引入继承和多态。典型题目是“定义动物类，子类有猫和狗，重写叫声方法”。答案里父类往往写一个public void makeSound() {}，里面什么都不做。很多人不理解：既然什么都不做，为什么要写？

这里涉及一个设计意图：父类定义“能做什么”，子类决定“怎么做”。父类的方法是一个契约，告诉调用者“所有动物都能叫”，但具体叫声由子类实现。如果你在父类里写具体逻辑，反而限制了子类的灵活性。练习题里这个空方法就是多态的入口。

我实际带人时发现，大家最容易犯的错是：在测试类里写一堆if (animal instanceof Cat)来判断类型，然后分别调用。这等于把多态又写回了过程式代码。正确做法是直接animal.makeSound()，让Java自己决定调用哪个子类的方法。

public abstract class Animal { public abstract void makeSound(); } public class Cat extends Animal { @Override public void makeSound() { System.out.println("喵喵"); } } public class Dog extends Animal { @Override public void makeSound() { System.out.println("汪汪"); } }

用abstract比空方法更好，因为它强制子类必须实现。练习题答案如果只给空方法，你可以自己升级成抽象方法，这是从“做完”到“做对”的一步。

2.4 接口题：什么时候用接口，什么时候用抽象类

第五章有些练习题会同时出现接口和抽象类，新手最容易混。我自己的判断标准很简单：如果多个类共享的是“是什么”，用抽象类；如果共享的是“能做什么”，用接口。比如“学生”和“老师”都是“人”，用抽象类Person；但“学生”和“课程”都能“被打印”，用接口Printable。

练习题里经常要求“定义一个接口，然后两个类实现它”。这时候注意：接口里的方法默认是public abstract，不用写修饰符；实现类必须用@Override标出来，虽然不写也能编译，但写了之后编译器会帮你检查方法签名对不对。

我见过一个典型错误：接口里定义了void print();，实现类里写成public void Print()，大小写不一样，结果没报错但也没实现接口方法。加上@Override立刻就会报错，省得你调试半天。

3. 集合与异常题：答案只给结果，但过程才是重点

3.1 ArrayList和HashMap的练习题：为什么你的输出顺序总是不对

第五章集合部分的练习题，常见要求是“存储多个对象，然后遍历输出”。很多人用HashMap存数据，发现输出顺序和插入顺序不一样，就以为代码写错了。其实HashMap本来就不保证顺序，这是它的特性，不是bug。

如果练习题要求按插入顺序输出，应该用LinkedHashMap；如果要求按key排序，用TreeMap。答案里如果只写HashMap，你得看清楚题目有没有顺序要求。我一般建议新手在练习题阶段就养成习惯：先问顺序要求，再选集合类型。

// 不保证顺序 Map<String, Integer> map1 = new HashMap<>(); // 保证插入顺序 Map<String, Integer> map2 = new LinkedHashMap<>(); // 按key自然排序 Map<String, Integer> map3 = new TreeMap<>();

另外，遍历HashMap时如果同时删除元素，直接用for-each会抛ConcurrentModificationException。正确做法是用Iterator或者removeIf。这个坑在练习题里不一定遇到，但只要你写稍微复杂一点的逻辑就会撞上。

3.2 异常处理题：catch块里到底该写什么

第五章异常部分的练习题通常要求“处理可能出现的异常”。答案里经常出现catch (Exception e) {}，里面什么都不写，或者只写e.printStackTrace()。这两种写法在实际项目中都是大忌：前者叫“吞异常”，出了问题你根本不知道；后者只是打印，程序继续往下跑，可能带着错误数据继续执行。

我建议练习题阶段就按这个结构写：

try { // 可能出错的代码 } catch (NumberFormatException e) { System.err.println("输入的不是合法数字：" + e.getMessage()); // 给出默认值或者重新提示用户 } catch (ArithmeticException e) { System.err.println("算术错误：" + e.getMessage()); }

尽量捕获具体异常，而不是笼统的Exception。这样你能针对不同错误做不同处理。如果题目要求“程序不能崩溃”，那catch之后要给一个合理的默认行为，而不是让程序继续用错误数据跑。

3.3 自定义异常：练习题里最容易被忽略的“加分项”

有些第五章练习题会要求“当余额不足时抛出异常”。很多人直接throw new RuntimeException("余额不足")，能跑，但不够好。更好的做法是定义一个InsufficientBalanceException extends Exception，这样调用者可以精确捕获这个异常，而不是捕获所有RuntimeException。

public class InsufficientBalanceException extends Exception { public InsufficientBalanceException(String message) { super(message); } }

然后在取款方法里：

public void withdraw(double amount) throws InsufficientBalanceException { if (amount > balance) { throw new InsufficientBalanceException("余额不足，当前余额：" + balance); } balance -= amount; }

这个改动不大，但体现了你对异常体系的理解。练习题答案如果没这么做，你可以自己加上，面试时被问到“你怎么处理业务异常”也有东西可说。

4. 文件IO与综合题：从“能跑”到“能交差”差在哪

4.1 文件读写题：为什么你的中文变成乱码

第五章最后通常会有文件读写的综合练习题，比如“从文件读取学生成绩，计算平均分后写入另一个文件”。很多人写完发现中文全是乱码，原因是用了默认字符集。Java的FileReader和FileWriter使用平台默认编码，在不同系统上结果不一样。

正确做法是明确指定UTF-8：

try (BufferedReader reader = new BufferedReader( new InputStreamReader(new FileInputStream("input.txt"), StandardCharsets.UTF_8)); BufferedWriter writer = new BufferedWriter( new OutputStreamWriter(new FileOutputStream("output.txt"), StandardCharsets.UTF_8))) { String line; while ((line = reader.readLine()) != null) { // 处理每一行 writer.write(line); writer.newLine(); } } catch (IOException e) { System.err.println("文件操作失败：" + e.getMessage()); }

用try-with-resources可以自动关闭流，不用写finally块。这是第五章应该掌握的标准写法，比答案里常见的try-finally更简洁，也不容易漏关。

4.2 综合题拆解：一个“学生成绩管理”的完整思路

假设题目要求：从文件读取学生姓名和三门课成绩，计算总分和平均分，按平均分降序输出到控制台，并把结果写入新文件。这道题覆盖了类设计、集合、异常、文件IO、排序，是第五章的典型综合题。

我的拆解步骤是：

1. 定义Student类：姓名、三门课成绩、总分、平均分。总分和平均分可以在构造时计算，也可以提供计算方法。
2. 读取文件：用BufferedReader按行读，每行按逗号或空格拆分，解析成Student对象，放入List<Student>。
3. 异常处理：文件不存在、格式错误、数字解析失败，分别处理。
4. 排序：用Collections.sort配合Comparator，按平均分降序。
5. 输出：遍历List打印，同时用BufferedWriter写入文件。

List<Student> students = new ArrayList<>(); // 读取和解析... students.sort((s1, s2) -> Double.compare(s2.getAverage(), s1.getAverage()));

这里用Lambda表达式比匿名内部类简洁得多。第五章如果还没讲Lambda，用匿名内部类也行，但建议提前了解，因为后面会大量使用。

4.3 练习题答案里不会告诉你的“边界测试”

我批改过很多人的练习题，发现大家普遍只测“正常数据”：文件存在、格式正确、数字合法。但真实场景里，文件可能为空、某行可能少一个字段、成绩可能是“abc”。这些边界情况练习题答案通常不涉及，但恰恰是区分“会写代码”和“能交付”的关键。

我自己的习惯是，每写完一个文件读取逻辑，至少手动构造这几种测试数据：

把这些测一遍，你的代码才算真正“做完”。这也是我在实际项目中要求新人的最低标准。

5. 我踩过的坑和给你的实操建议

5.1 不要一上来就打开IDE，先用纸笔写伪代码

我刚开始学Java时，第五章练习题也是直接抄答案。后来带人发现，抄答案最大的问题是：你跳过了“设计”这一步。正确的做法是，读完题目后，先在纸上写三样东西：类名、属性、方法签名。比如“银行账户”题，纸上写：

• 类：Account
• 属性：accountNumber, balance
• 方法：deposit(double), withdraw(double), getBalance()

写完再打开IDE，把纸上的东西翻译成代码。这个过程慢，但练几次之后，你看到任何题目都能快速拆解。我现在的习惯是，哪怕写一个很小的工具类，也会先在注释里把结构列出来，再填实现。

5.2 答案里的代码不一定是最优解，学会“改答案”

练习题答案通常只保证“能跑”，不一定符合最佳实践。比如答案里可能用Vector而不是ArrayList，可能用String拼接而不是StringBuilder，可能不处理异常。你可以在答案基础上做三个改动：

1. 把能改的集合换成更合适的：Vector换ArrayList，Hashtable换HashMap。
2. 把字符串拼接换成StringBuilder：循环里拼接字符串用+会产生大量临时对象。
3. 把异常处理补全：至少打印有意义的错误信息，不要空catch。

这三个改动花不了多少时间，但能让你的代码质量上一个台阶。而且改的过程中，你会真正理解为什么有些写法更好。

5.3 用Git记录每一次修改，哪怕只是练习题

我建议从第五章开始，把每一道练习题都建一个文件夹，用Git管理。每做完一题提交一次，改进了也提交一次。这样你回头能看到自己从“能跑”到“写得好”的整个过程。更重要的是，当你后面遇到类似问题时，可以直接翻之前的提交记录，比重新搜答案快得多。

git init git add Student.java git commit -m "完成学生类基本属性和方法" git add StudentTest.java git commit -m "添加测试类，验证成绩校验逻辑"

这个习惯看起来小题大做，但等你写到第十章、做课程设计时，会感谢自己当初留了这些记录。

5.4 遇到卡壳超过20分钟，先跳过，别死磕

第五章有些综合题确实难，卡住很正常。我的经验是：如果一道题卡了20分钟还没思路，先跳过，做下一题。很多时候，你在做下一题时突然就想通了上一题。或者过一天再看，思路会清晰很多。死磕不仅效率低，还容易打击信心。

另外，卡住时不要直接搜“第五章练习题答案”，而是搜具体问题，比如“Java ArrayList排序 Comparator”或者“Java读取文件中文乱码”。这样搜到的内容更有针对性，也能帮你真正解决问题，而不是抄一个答案继续卡下一题。

6. 从练习题到真实项目：第五章之后该往哪走

第五章练习题做完，你大概能写几百行的单文件程序了。但真实项目通常是多文件、分层、有依赖管理的。我的建议是，做完第五章后，不要急着往后翻，而是用第五章的知识做一个“稍微大一点”的东西。比如：

• 一个命令行版的学生成绩管理，数据存文件，支持增删改查。
• 一个简单的图书借阅系统，用集合存数据，用异常处理借阅规则。
• 一个文本文件分析工具，统计词频、行数、最长行。

这些项目不需要新知识，但会逼你把类设计、集合、异常、文件IO串起来。做完一个，你对第五章的理解会完全不一样。而且这些项目可以写进简历，比“完成了第五章练习题”有说服力得多。

我自己带人时，通常要求做完第五章后交一个这样的迷你项目，代码量在300到500行之间，有基本的异常处理和文件读写。能独立完成这个，后面学框架、学数据库都会顺很多。因为你会发现，不管技术怎么变，把需求拆成类、把数据放进集合、把错误处理清楚、把结果输出到该去的地方，这套逻辑是不变的。

最后说一个我自己的体会：第五章练习题的价值，不在于你做出了多少道，而在于你有没有从“抄答案”变成“自己设计”。哪怕你只认真做了三道题，每道都按“纸笔设计→编码→边界测试→改进”的流程走一遍，收获也比抄二十道答案大。Java基础就像盖楼，第五章是打地基的最后一步，这里偷的懒，后面迟早要还。