17考试准备：用这份代码答题

前面 16 章讲的是代码本身。这一章只做一件事：把这些代码变成考试答案。卷子上印着你的 UML，题目是英文，答案也要用英文写。下面用三道样题做例子，每道题都按同一个顺序来：先看真实截图上发生了什么，再找到做这件事的类和方法，然后一句一句把答案搭起来，最后给出可以直接背的英文参考答案。

截图来自两局真实的游戏。A 局：你选 Impike，在 (17,17) 森林里的感叹号上遇到 Galecrest，最后打赢了（第 11 章一回合一回合讲过这一局）。B 局：你选 Shellurk，在 (12,12) 草地上的感叹号遇到 Nightwing，打到一半用菜单逃跑（第 15 章）。

这一章不再重新解释代码。用到的词都在前面讲过：实例化（instantiation）、包含关系（containership）、委托（delegation）的定义和代码例子在 第 16 章第 9 节；谁 new 了谁、谁存着谁的全图在 第 10 章第 7 节；一个回合的每一行在 第 11 章；逃跑的完整流程在 第 15 章；设计模式和 SOLID 的位置在 第 16 章。本章出现的 Java 写法，在出现的地方都有一句话解释；想看完整的，查 第 2 章。

1. 三类题：阅卷人想看到什么

样题有三道，正好是三种题型。不管哪一种，好答案都走同样的四步：

1. 找到位置：在卷子印的 UML 上找到题目说的那几个类。
2. 点名：写出字段名和方法名（battle、playTurn(skill)），不要只写类名。
3. 串起来：按“谁创建谁 → 谁存着谁 → 谁调用谁”的顺序说一遍。
4. 说理由：每个“好”或“不好”后面都跟一个 because。

三个课程用语在答案里出现得最多。下面每一个都配一句你代码里真实的例子，答题时就照这个格式写：

三个词常常落在同一对类上。下面这张小图上的三条线，在你的代码里都真实存在：

2. 样题 Q1（交互题）：同一个回合里处理两边的数据

样题大意：找到你的 Project 2 里，在同一个战斗回合的操作中处理和玩家、敌人两边数值有关的数据的位置。哪些类参与？它们在 instantiation、delegation、containership 上怎样配合？这样设计有什么好处？

2.1 先看屏幕：一个回合改了两个人的数据

A 局第 2 回合：你点了 Stun [4]，敌人随后用了 Tackle。只点了一下，屏幕上两个人的数据都变了：

1234

1. 1
   你的能量 33 → 29：你的 Stun 花了 4
2. 2
   敌人的能量 14 → 9：敌人的 Tackle 花了 5
3. 3
   日志区（下面放大）
4. 4
   你的 HP 还是 225 / 225（为什么，看下面的框 6）

56

1. 5
   日志第 9 行：你的 Stun 打中了。敌人的 Fighter 身上多了一个 Stunned 效果，屏幕上只有这句话看得到它
2. 6
   日志第 11 行：敌人的 Tackle 没打中，所以你的 HP 没变

把这一回合前后（battle-wait → battle-stun）的两根能量条并排放。同一个数字代表同一样东西：

1

1. 1
   点 Stun 之前：你的能量 33 / 33

1

1. 1
   之后：29 / 33（33 − 4）

2

1. 2
   之前：敌人的能量条是满的（14 / 14）

2

1. 2
   之后：9 / 14（14 − 5），条短了一截

敌人的条上不写数字（只有你的面板用 CLabelledStatBar），14 和 9 是程序运行时 CFighter 里的真实值。这道题要你讲的，就是“这些数字存在哪、谁改的、谁画出来的”。

2.2 谁创建了这些对象（instantiation）

回合开始之前，对象就已经造好了。你在遇敌对话框里点 Fight! 的时候，按下图箭头上 1 到 8 的顺序发生：

• 箭头 1：Fight! 按钮的 lambda 在 COverworldScreen.onEncounter 里（第 85–88 行）：先 closeDialog()，再 getNavigator().startBattle()。它只认识接口 IGameNavigator，背后的对象是 CGameWindow。
• 箭头 2、3：CGameWindow.startBattle 第 67 行先算括号里的 world.createBattle()；COverworld 再把 player.getInventory() 交给 encounter.createBattle(…)。
• 箭头 4、5、6：CEncounter.createBattle new 两个 CFighter 和一个 CBattle；CBattle 的构造器顺手 new 一个 CRandomEnemyStrategy（下面的代码）。
• 箭头 7、8：回到第 67 行：拿着这个 CBattle new CBattleScreen，它的构造器第 78、81 行 new 两个 CFighterPanel。

为什么是 Encounter 来 new？造 CFighter 需要三样东西：你的 Mokepon、敌人的 Mokepon、这一格的地形。它们正好都是 CEncounter 的字段 playerMokepon、enemy、terrain（第 17–19 行）。谁有数据，就由谁来造。英文：Encounter creates the fighters because it already has everything they need: both Mokepon and the terrain of the marker's tile.

中间那一步的代码只有 3 行。先看代码，再看它造出来的东西刚出现在屏幕上的样子，红色数字一一对应（鼠标移到图下的说明上，代码里同一个数字会亮）：

52    /* Start a battle where the terrain changes the stats of both fighters. */
53    public Battle createBattle(Inventory inventory) {
541        Fighter player = new Fighter(playerMokepon, getPlayerEffect());
552        Fighter enemyFighter = new Fighter(enemy, getEnemyEffect());
563        return new Battle(player, enemyFighter, inventory);
57    }

12

1. 1
   player：用你的 Impike 造的 Fighter，HP 225
2. 2
   enemy：用 Galecrest 造的 Fighter

3

1. 3
   Battle 的构造器写下的日志第一行

• 第 54 行（标 1）：new Fighter(playerMokepon, getPlayerEffect())。Impike 是 FIRE，这个感叹号在 FOREST 上，getEffectOn 返回 ADVANTAGE（×1.5）。CFighter 构造器把每个数值乘一遍再 limit：HP 150（Impike 原来的 HP）× 1.5 = 225。
• 第 55 行（标 2）：敌人也一样，只是参数换成敌人的。Galecrest 是 LIGHTNING，在 FOREST 上是 DISADVANTAGE（×0.5）：HP 185 × 0.5 = 92.5，Math.round 四舍五入成 93。
• 第 56 行（标 3）：new Battle(player, enemyFighter, inventory)。这是 3 个参数的构造器，它用 this(...) 转给 5 个参数的构造器，顺手 new RandomEnemyStrategy() 和 new Random()，最后写下日志第一行。

inventory 不是新造的：它是 COverworld 构造器里 new Inventory(ItemCatalogue.getAll()) 造好、交给 CPlayer 存着的那一个。COverworld.createBattle 把 player.getInventory() 传进来，所以战斗里用掉的道具，回到地图上也少了。造对象的细节见 第 10 章。

2.3 一句一句搭答案

参考答案一共 10 句，用两个动画来搭。第一个讲第 1–4 句：位置、谁创建、谁存着、谁委托。图里：空心菱形 = 用字段存着（边上是字段名），实线箭头 = 调用，虚线箭头 = 用 new 创建；两个 CFighter 方框是同一个类的两个对象，CFighterPanel 方框代表 playerPanel、enemyPanel 两个对象。左下是这一句说的代码，右下是它在屏幕上的结果。斜体是可以照写的英文句子。动画里亮起来的线会变成红色的流动虚线，那只表示“这一步讲的是它”，和“虚线 = new”无关。

188        for (Skill skill : skills) {
189            GameButton button = new GameButton(skill.getName() + " [" + skill.getEnergyCost()
190                    + "]", font, BUTTON_RADIUS);
191            button.setPrefSize(SKILL_WIDTH, SKILL_HEIGHT);
192            button.addPressEffect();
193            button.setOnAction(event -> useSkill(skill));
194            skillButtons.add(button);
195            buttonColumn.getChildren().add(button);
196        }

52    /* Start a battle where the terrain changes the stats of both fighters. */
53    public Battle createBattle(Inventory inventory) {
54        Fighter player = new Fighter(playerMokepon, getPlayerEffect());
55        Fighter enemyFighter = new Fighter(enemy, getEnemyEffect());
56        return new Battle(player, enemyFighter, inventory);
57    }

15    private final Fighter player;
16    private final Fighter enemy;
17    private final Inventory inventory;
18    private final EnemyStrategy enemyStrategy;
19    private final Random random;
20    private final List<String> log = new ArrayList<>();

117    private void useSkill(Skill skill) {
118        battle.playTurn(skill);
119        update();
120    }

1

1. 1
   你点的 Stun [4]（一个 GameButton）

12

1. 1
   HP：150 × 1.5 = 225
2. 2
   Energy：22 × 1.5 = 33

12

1. 1
   player 的数据
2. 2
   enemy 的数据

1. 第 1 句：说位置。The data of both fighters is handled in Battle.playTurn(Skill), which BattleScreen starts when a skill button is pressed. 亮的是这两个类。CBattleScreen.createSkillButtons 给每个技能做一个 CGameButton，第 193 行用 lambda event -> useSkill(skill) 登记“点了以后做什么”，它记住了这一次循环的 skill（Stun 对象）。按数字键 2 也是“按下”同一个按钮（fire()），走同一个 lambda。
2. 第 2 句：instantiation。When the player clicks Fight!, the dialog button in OverworldScreen calls getNavigator().startBattle(); GameWindow.startBattle() calls world.createBattle(), which passes the player's inventory to encounter.createBattle(inventory). Encounter.createBattle creates two Fighter objects, one from each Mokepon with its terrain effect, and a new Battle(player, enemyFighter, inventory). GameWindow then creates a new BattleScreen for this Battle. 亮的是三条虚线（new），就是第 54–56 行。Impike 在 FOREST 上 ×1.5：HP 150 → 225（框 1），Energy 22 → 33（框 2）。前面那段调用链（Fight! → startBattle → createBattle）是 2.2 节图上的箭头 1–3。
3. 第 3 句：containership。Battle holds the two fighters in its private final fields player and enemy, together with the player's Inventory, the EnemyStrategy in enemyStrategy and the log; each Fighter keeps its own stats and status effects and a reference to its read-only Mokepon. 亮的是 5 个空心菱形。第 17、19、20 行还存着 inventory、random、log（图里没画）；CFighter 的 mokepon、stats、effects 在 Fighter.java 第 21、25、26 行。两边的数值分开存，所以左边卷轴只画 player（框 1），右边只画 enemy（框 2）。
4. 第 4 句：delegation。The skill button's lambda calls BattleScreen.useSkill(skill), which delegates the whole turn to battle.playTurn(skill). 亮的是“存着”（CBattleScreen 的字段 battle）和下面那条弯的“调用”（playTurn）。CBattleScreen 自己不算任何规则：第 118 行交给 CBattle，第 119 行 update() 重画。

第二个动画讲第 5–10 句：一个回合里谁调用谁。图里只有实线箭头（调用），箭头上是这一回合真实调用的方法。skill 方框前半回合是你的 Stun 对象，后半回合是敌人挑出来的 Tackle 对象。

79        log.add("");
80        log.add("Player's " + player.getName() + " used " + playerSkill.getName() + "!");
81        log.add(playerSkill.use(player, enemy, random));
⋯ 省略第 82–86 行
87        Skill enemySkill = enemyStrategy.chooseSkill(enemy, random);
88        log.add("Enemy " + enemy.getName() + " used " + enemySkill.getName() + "!");
89        log.add(enemySkill.use(enemy, player, random));

27    /* Template Method: pay the energy cost first (even if an attack then misses),
28     * then apply the effect. Returns the message for the battle log.
29     */
30    public final String use(Fighter user, Fighter target, Random random) {
31        user.spendEnergy(energyCost);
32        return applyEffect(user, target, random);
33    }

18    protected final String applyEffect(Fighter user, Fighter target, Random random) {
19        if (!hits(user, target, random)) {
20            return MISS_MESSAGE;
21        }
22        return applyHit(user, target, random);

16    protected String applyHit(Fighter user, Fighter target, Random random) {
17        target.addEffect(new Stunned());

95        endTurn();
⋯ 省略第 96–115 行
116    private void endTurn() {
117        log.addAll(enemy.applyLingeringDamage());
⋯ 省略第 118–122 行
123        log.addAll(player.applyLingeringDamage());
⋯ 省略第 124–128 行
129        enemy.countDownEffects();
130        player.countDownEffects();

81        log.add(playerSkill.use(player, enemy, random));
82        if (!enemy.isAlive()) {
83            finish(true);
84            return;
85        }
⋯ 省略第 86–138 行
139        if (playerWon) {
140            log.add("Enemy's " + enemy.getName() + " fainted!");
141            log.add("You win");

128    private void update() {
129        playerPanel.update();
130        enemyPanel.update();
131        showLog();
132        updateSkillButtons();
133        updateItemButtons();

12

1. 1
   第 9 行：Stun 返回的话
2. 2
   第 11 行：Tackle 返回的话

1

1. 1
   你的能量 33 → 29

1

1. 1
   敌人的能量 14 → 9

123

1. 1
   第 13 行：Poison
2. 2
   第 16 行：Lance 83 伤害
3. 3
   第 19–20 行：finish(true)

1

1. 1
   第 9 行的后半句：Stunned 管 3 回合（Stunned.TURNS = 3）

123

1. 1
   playerPanel
2. 2
   enemyPanel
3. 3
   logArea

1. 第 5 句：同一个方法给两边用。playTurn uses the same method for both sides: playerSkill.use(player, enemy, random) and then enemySkill.use(enemy, player, random), so one piece of code changes both fighters' data. 第 81 行和第 89 行只是把两个 CFighter 换了位置。框 1、框 2 是这两次调用各自返回、被 log.add 写进日志的话。规则只写一份，这就是 DRY。
2. 第 6 句（前半）：先付能量。Skill.use is a final template method that calls user.spendEnergy(cost) and then applyEffect; … 第 31 行的 energyCost 就是句子里的 cost。你出手时 user 是你：33 − 4 = 29（框 1）。顺序写死在 final 方法里，子类改不了，所以能量总是先扣，打没打中都一样（第 27 行的注释也这么说）。
3. 第 6 句（后半）：打中了才改对方。… for targeted skills TargetedSkill.applyEffect first does the hit check and only then calls applyHit, which changes the target only through Fighter methods such as takeDamage() and addEffect(). Stun 和 Tackle 都是 ATargetedSkill。你的 Stun 判定命中，走到第 22 行，CStun.applyHit 第 17 行 target.addEffect(new Stunned())（框 1）。敌人的 Tackle 没中，第 20 行直接返回 MISS_MESSAGE，就是 "But they missed."（框 2）。命中怎么算见 第 12 章。
4. 第 7 句：敌人的技能谁来挑。The enemy's skill is chosen by enemyStrategy.chooseSkill(enemy, random); the field's type is the EnemyStrategy interface, and the default object is a RandomEnemyStrategy. 这是策略模式（Strategy）：CBattle 的 3 个参数的构造器往这个字段里放了一个 CRandomEnemyStrategy。这次挑到 Tackle。第 89 行 user 换成敌人：14 − 5 = 9（框 1）。Tackle 没打中，能量照样扣了，因为 spendEnergy 在命中判定之前。
5. 第 8 句（前半）：有人倒下就结束。After each action Battle checks isAlive() and calls finish() if someone fainted; … 点 Stun 那一回合没人倒下，所以这里借 A 局最后一回合来看。先用道具 Poison，敌人 HP 变成 1（框 1，道具不占回合）。再点 Lance，打出 83（框 2）：takeDamage 里 Math.max(0, 1 − 83) = 0，isAlive() 为 false，第 83 行 finish(true) 写下框 3 的两行，第 84 行 return，敌人没机会出手。
6. 第 8 句（后半）：没人倒下就 endTurn。… otherwise endTurn() applies the enemy's lingering damage, then the player's, and counts down both fighters' effects. 回到点 Stun 那一回合：两人都站着，走到第 95 行 endTurn()：先 enemy 的、再 player 的 applyLingeringDamage()，最后两边 countDownEffects()。Stun 那句日志说眩晕 3 回合（框 1），这里倒数一次后，Galecrest 的 Stunned 还剩 2 回合（屏幕上看不到这个数，见 第 13 章）。
7. 第 9 句：屏幕怎么跟上。Finally BattleScreen.update() reads the new state through getters and calls playerPanel.update() and enemyPanel.update() to redraw both fighters. 每个 CFighterPanel 用字段 fighter 存着一个 CFighter，只读不改（框 1、2）；第 131 行 showLog() 把 battle.getLog() 返回的只读列表显示在日志区（框 3）。
8. 第 10 句：好处（because）。This design is good because the turn rules are written once for both fighters, Battle has a single responsibility and no JavaFX code, and a new skill or enemy strategy can be added without changing playTurn. 三个理由分别对应：DRY（规则只写一份）、SRP（CBattle 只管规则）、OCP（加新东西不改 playTurn）。

2.4 如果要你画：一个回合的顺序图

考试可能让你画图说明。读法见 第 1 章第 3 节：每根竖虚线是一个对象，从上往下是时间，实线箭头 = 调用，虚线箭头 = 返回，绕回自己 = 调用自己的方法。一个回合太长，分成两张画：先是你出手，然后是敌人出手和回合末。

① 的第 5 个箭头就是 CStun.applyHit 里的 target.addEffect(new Stunned())。② 里 Tackle 没打中（第 5 个箭头），所以没有箭头碰 player 的 HP；如果打中了，AAttackSkill.applyHit 会多一个 target.takeDamage(damage)，target 是 player。playTurn 返回以后，CBattleScreen.useSkill 再调用自己的 update()。每一行的细节见 第 11 章。

2.5 参考答案

每一条先是中文要点，下面一行斜体是对应的英文句子；编号和上面两个动画的“第几句”一样，英文也一字不差（第 11 章第 8 节引用的也是这一份）。考试时按顺序写下这 10 句斜体，就是完整的答案。

1. 位置：CBattle.playTurn(Skill)，由 CBattleScreen 的技能按钮启动
   The data of both fighters is handled in Battle.playTurn(Skill), which BattleScreen starts when a skill button is pressed.
2. instantiation：点 Fight! → COverworldScreen 的按钮调用 startBattle() → CGameWindow 调用 world.createBattle() → COverworld 把背包交给 encounter.createBattle(…) → CEncounter new 两个 CFighter 和 CBattle → CGameWindow new CBattleScreen
   When the player clicks Fight!, the dialog button in OverworldScreen calls getNavigator().startBattle(); GameWindow.startBattle() calls world.createBattle(), which passes the player's inventory to encounter.createBattle(inventory). Encounter.createBattle creates two Fighter objects, one from each Mokepon with its terrain effect, and a new Battle(player, enemyFighter, inventory). GameWindow then creates a new BattleScreen for this Battle.
3. containership：CBattle 的 private final 字段 player、enemy、inventory、enemyStrategy、log；每个 CFighter 有自己的 stats、effects，并存着只读的 CMokepon
   Battle holds the two fighters in its private final fields player and enemy, together with the player's Inventory, the EnemyStrategy in enemyStrategy and the log; each Fighter keeps its own stats and status effects and a reference to its read-only Mokepon.
4. delegation：按钮的 lambda → useSkill → battle.playTurn(skill)
   The skill button's lambda calls BattleScreen.useSkill(skill), which delegates the whole turn to battle.playTurn(skill).
5. 两边共用：同一个 Skill.use(user, target, random)，参数位置一换就从你变成敌人
   playTurn uses the same method for both sides: playerSkill.use(player, enemy, random) and then enemySkill.use(enemy, player, random), so one piece of code changes both fighters' data.
6. 改数据只走 Fighter 的方法：Skill.use（final）先 spendEnergy；ATargetedSkill 先判定命中，中了才 applyHit；改对方只用 takeDamage、addEffect
   Skill.use is a final template method that calls user.spendEnergy(cost) and then applyEffect; for targeted skills TargetedSkill.applyEffect first does the hit check and only then calls applyHit, which changes the target only through Fighter methods such as takeDamage() and addEffect().
7. 敌人的技能：enemyStrategy.chooseSkill（策略模式），默认是 CRandomEnemyStrategy
   The enemy's skill is chosen by enemyStrategy.chooseSkill(enemy, random); the field's type is the EnemyStrategy interface, and the default object is a RandomEnemyStrategy.
8. 收尾：每次出手后 isAlive() → finish()；否则 endTurn()：先算敌人的持续伤害，再算你的，最后两边 countDownEffects() 倒数
   After each action Battle checks isAlive() and calls finish() if someone fainted; otherwise endTurn() applies the enemy's lingering damage, then the player's, and counts down both fighters' effects.
9. 显示：update() 通过 getter 读，两个 CFighterPanel 重画，showLog() 显示 getLog()
   Finally BattleScreen.update() reads the new state through getters and calls playerPanel.update() and enemyPanel.update() to redraw both fighters.
10. because：规则只写一份（DRY）；CBattle 只管规则、没有 JavaFX（SRP）；加新技能、新策略不用改 playTurn（OCP）
    This design is good because the turn rules are written once for both fighters, Battle has a single responsibility and no JavaFX code, and a new skill or enemy strategy can be added without changing playTurn.

3. 样题 Q2（原则题）：接口隔离原则 ISP

样题大意：我们学过的一个 OOP 原则是接口隔离原则（Interface Segregation Principle）。给出它的定义，并在你的 Project 2 里指出一个它被用到或者本该用到的位置或交互。如果哪里都没用到，说明要怎样改结构才能用上。

3.1 定义

接口隔离原则（ISP）：不要逼一个使用者依赖它用不到的方法。与其做一个什么都有的大接口，不如做几个小的、专门的接口，每个使用者只看到自己要用的那几个方法。这里的“使用者（client）”是指调用这个接口的类。

英文定义，一句就够：The Interface Segregation Principle says that no client should be forced to depend on methods it does not use, so several small, focused interfaces are better than one large one.

3.2 选哪个位置：三个候选

• (a) IGameNavigator：菜单和三个画面在用；7 个方法，每个使用者只用 1–3 个。它是反例，适合写“本该用到 ISP 的地方”（3.4）。
• (b) IEnemyStrategy、IEnemyPicker：CBattle、CMarker 在用；各 1 个方法。可以写，作为补充例子。
• (c) IOverworldListener：COverworld 在用；5 个方法，全是地图世界的事件。推荐：有一个大类（COverworldScreen）可以对比，交互两边都能讲具体。

为什么推荐 (c)？题目要的是“位置或交互”。IOverworldListener 有清楚的两边：一边是只调用 5 个方法的 COverworld，另一边是方法多得多的 COverworldScreen。你能说出 COverworld “看不到”哪些方法，这就是 ISP 的核心。(b) 也对，但一个方法的接口很难说出“隔离”了什么。

3.3 推荐答案的位置：OverworldListener

再看谁用它、谁实现它，以及 COverworld 看不到的是哪些方法：

• 使用者是 COverworld。它的字段 listeners 的类型是 List<OverworldListener>（第 23 行）。它只通过 notifyListeners(listener -> listener.onXxx(...)) 调用这 5 个方法，别的什么都不调用。
• 实现者是 COverworldScreen（extends GameScreen implements OverworldListener）。它自己写的 public 方法只有构造器和这 5 个接口方法；另外它从 AGameScreen 继承了 getView()、handleKeyPress()、canRunAway()、canReturnToMainMenu() 这些 public 方法（GameScreen.java 第 24–49 行）。因为字段类型是接口，COverworld 根本看不到它们。
• 登记：CGameWindow.startGame 第 61 行 world.addListener(overworldScreen)。

用一个真实的交互说明：A 局赢了 Galecrest，点 Back to it! 以后，CGameWindow.winBattle 调用 world.winEncounter()。先看前后两张截图（左边是遇敌前一步，右边是赢了回到地图），再看做这件事的两段代码。编号前后一样，鼠标移到说明上，代码里同一个数字会亮：

13

1. 1
   (17,17) 的绿色感叹号。它右边的白色星形就是你（MapView.playerView），在 (18,17)
2. 3
   状态栏是空的

13

1. 1
   (17,17)：感叹号没了，你站在这里
2. 3
   状态栏：You beat the enemy Galecrest!

2

1. 2
   Fights: 0

2

1. 2
   Fights: 1

93    /* The battle was won, so remove the marker and count the win. */
94    public void winEncounter() {
95        Mokepon enemy = encounter.getEnemy();
961        objects.remove(encounter.getMarker());
972        player.addWin();
98        encounter = null;
993        notifyListeners(listener -> listener.onEncounterWon(enemy));
100    }

102    @Override
103    public void onEncounterWon(Mokepon enemy) {
1043        statusBar.setText("You beat the enemy " + enemy.getName() + "!");
1052        update();
106    }

• 标 1：第 96 行 objects.remove(encounter.getMarker()) 把这个感叹号从地图的物体列表里拿掉。
• 标 2：第 97 行 player.addWin() 改数据；第 105 行 update() 让卷轴重新读 CPlayer，屏幕上才变成 1。
• 标 3：第 99 行只知道“通知所有监听者：赢了这个敌人”。真正收到的是 COverworldScreen，它的第 104 行改状态栏。

COverworld 不知道监听者会改状态栏、刷新卷轴，也不用 import 任何 JavaFX 类（第 8 章讲过整个通知过程）。

3.4 本该用到 ISP 的地方：GameNavigator

7 个方法，每个使用者只用其中几个：

最明显的是 CGameMenu：它的构造器参数是 IGameNavigator，只用了 runAway()、returnToMainMenu()、quit() 三个（第 22、26、30 行），却依赖着全部 7 个。startGame(Mokepon) 一改参数，CGameMenu 也跟着要重新编译。

15    private final MenuBar menuBar;
16    private final MenuItem runAway;
17    private final MenuItem mainMenu;
18 
19    public GameMenu(GameNavigator navigator) {
20        runAway = new MenuItem("Run away");
21        runAway.setAccelerator(new KeyCodeCombination(KeyCode.R, KeyCombination.CONTROL_DOWN));
221        runAway.setOnAction(event -> navigator.runAway());
23 
24        mainMenu = new MenuItem("Main menu");
25        mainMenu.setAccelerator(new KeyCodeCombination(KeyCode.B, KeyCombination.CONTROL_DOWN));
262        mainMenu.setOnAction(event -> navigator.returnToMainMenu());
27 
28        MenuItem exit = new MenuItem("Exit");
29        exit.setAccelerator(new KeyCodeCombination(KeyCode.F4, KeyCombination.ALT_DOWN));
303        exit.setOnAction(event -> navigator.quit());

改法要写到类和方法这一层：

1. 新建 interface MenuActions，把 runAway()、returnToMainMenu()、quit() 从 IGameNavigator 移过去。
2. IGameNavigator 改成 interface GameNavigator extends MenuActions，只留 startGame、startBattle、winBattle、updateMenu。
3. CGameMenu 的构造器改成 GameMenu(MenuActions actions)。
4. CGameWindow 一行不用改：它实现 IGameNavigator，也就自动实现了 MenuActions；第 39 行 new GameMenu(this) 照样能编译。

3.5 参考答案

和 2.5 一样：中文要点，下面是英文句子。按顺序写下 7 句斜体就是完整的答案。

1. 定义：不要逼使用者依赖它不用的方法，接口要小而专一
   The Interface Segregation Principle says that no client should be forced to depend on methods it does not use, so several small, focused interfaces are better than one large one.
2. 位置：IOverworldListener；使用者 COverworld 用字段 listeners 存着它，只调用 5 个通知方法
   In my Project 2 it is applied in the OverworldListener interface. Overworld is the client: it keeps its observers in the field listeners, a List of OverworldListener, and only ever calls the five notification methods onPlayerMoved, onEncounter, onItemCollected, onEncounterWon and onExitReached through notifyListeners().
3. 实现者和登记：COverworldScreen 实现它，CGameWindow.startGame 用 addListener 登记
   OverworldScreen implements this interface, and GameWindow.startGame() registers it with world.addListener(overworldScreen).
4. because：COverworld 看不到画面的其他方法，也不依赖 JavaFX
   Because Overworld depends only on this small interface, it cannot see OverworldScreen's other public methods such as getView(), handleKeyPress() or canRunAway(), and the world package does not need any JavaFX class.
5. 例子：winEncounter → onEncounterWon → 状态栏文字
   For example, when a battle is won, Overworld.winEncounter() removes the marker, counts the win and calls onEncounterWon(enemy), and the screen shows "You beat the enemy Galecrest!".
6. 补充：IEnemyStrategy、IEnemyPicker 各一个方法
   EnemyStrategy, used by Battle, and EnemyPicker, used by Marker, are two more interfaces with only one method each.
7. 不足和改法：IGameNavigator 7 个方法，CGameMenu 只用 3 个 → 拆出 MenuActions
   A place where the principle should have been applied is GameNavigator: it has seven methods, but GameMenu only uses runAway(), returnToMainMenu() and quit(). I would move these three methods into a new interface MenuActions, make GameNavigator extend it, and change the GameMenu constructor to take a MenuActions, so the menu no longer depends on methods like startGame() or startBattle().

4. 样题 Q3（扩展题）：加上 Run away

样题大意：Project 2 要求玩家能在战斗中逃跑（Game 菜单里的 Run away）。描述为了做到这一点，你在 Project 1 的结构上加了或改了哪些类和方法；Project 1 的设计哪里帮了忙、哪里让它更难；现在的做法好不好继续扩展。

4.1 先看屏幕

B 局：你的 Shellurk 走到 (12,12) 的感叹号上，遇到 Nightwing，点了 Fight!。战斗里连用 4 次 Aim，能量用光，然后打开 Game 菜单选 Run away。先看位置：同一块地图，左边是刚踩上感叹号的时候，右边是逃跑以后：

1

1. 1
   遇敌框：你踩上了 (12,12)，这一格正好被框盖住。这时 Player 的 previousPosition 记着上一格 (11,12)

12

1. 1
   (12,12) 的感叹号还在
2. 2
   白色星形就是你（MapView.playerView）：退回了感叹号左边那一格，也就是 (11,12)

中间发生的事：战斗里打开 Game 菜单，Run away 是黑字（框 3）。还有一个不显眼但最重要的变化：战斗里的数值全部消失了（框 4、5）：

3

1. 3
   Run away：黑字，可以点，快捷键 Ctrl+R

4

1. 4
   战斗里，Shellurk 的 Fighter：能量 0 / 12

45

1. 4
   回到地图：Mokepon 的 Energy 还是 12
2. 5
   Accuracy 还是 62：Aim 加的 16 点只加在 Fighter 上

Aim 4 次分别加了 3、1、7、5 点（日志里写着），Fighter 的 Accuracy 从 62 变成 62 + 16 = 78。可是卷轴（CPlayerStatsScroll）读的是 player.getMokepon()，CMokepon 一个数字都没变。这正是 Q3 要讲的设计。

4.2 Project 1 原来什么样

Project 1 没有地图，也没有逃跑。它的代码在 第 15 章第 9 节已经一段一段看过（逐条对比在 第 16 章第 10 节）。答这道题只要记住 4 点：

1. 菜单写在窗口类里：GameWindow extends Stage，一个类 591 行。菜单不是一个对象，而是两个现做菜单栏的方法 getSelectMenu() 和 getBattleMenu(...)；同样的 Exit（调用 Platform.exit()）写了两遍。
2. 菜单项直接调用窗口的 private 方法：战斗菜单里 Reset（Ctrl+R）和 Restart Battle 的 lambda 调用的是 GameWindow 自己的 resetSelectScreen() 和 battleScreen(...)。
3. Mokepon 会被战斗改掉：字段 hp、energy 不是 final，有 setHp 这样的 setter，takeDamage 直接改 hp。所以 battleScreen 开打前先用 copyMokepon 把两只各复制一份。
4. Battle 已经是单独的类：Project 1 的 Battle.java 没有一行 JavaFX，已经有字段 finished 和方法 isFinished()。

第 1–3 点在 4.5 节里是“拖后腿”的，第 4 点是“帮了忙”的。

4.3 Project 2 为 Run away 加了哪些类和方法

下面列出新加的 6 处：前 5 处按点下 Run away 以后的调用顺序排，第 6 处管的是 Run away 什么时候能点。每一处的代码、截图和一步一步的动画都在 第 15 章第 3 节（遇敌框里的 Run Away! 按钮在 第 2 节），这里只列名字和行号：答题时要写的就是这些名字。每条最后的“第几句”是 4.6 参考答案里对应的英文句子。

1. CGameMenu（新类）：菜单单独成了一个类。构造器第 20–22 行造 Run away 菜单项，快捷键 Ctrl+R，lambda event -> navigator.runAway()。navigator 只是构造器参数，不是字段（3.4 节的考试陷阱）。→ 第 2 句
2. IGameNavigator.runAway()（接口里新加的方法）：菜单只认识这个接口，不认识 CGameWindow。和 Project 1 不同，菜单不再调用窗口的 private 方法。→ 第 2 句
3. CGameWindow.runAway()：第 78 行 world.runAway() 把规则交给地图世界（委托），第 79 行 showScreen(overworldScreen) 换回原来的地图画面。→ 第 3 句
4. COverworld.runAway()：第 88 行 encounter = null，这次遇敌作废；第 89 行 player.moveBack()；第 90 行通知监听者 onPlayerMoved()，COverworldScreen 收到后重画地图（观察者模式）。感叹号没有被 remove，所以还在 (12,12)（4.1 “后”那张图的框 1）。→ 第 4 句
5. CPlayer 的字段 previousPosition 和方法 moveBack()：moveTo 第 41 行每走一步之前先记下旧格子，moveBack 第 47 行 position = previousPosition。B 局里记下的是 (11,12)（4.1 “后”那张图的框 2）。→ 第 4 句
6. AGameScreen.canRunAway() 和 CBattleScreen 的改写：AGameScreen 第 42–44 行默认 return false；CBattleScreen 第 103–105 行改写成 return !battle.isFinished()。CGameMenu.update 第 47 行 runAway.setDisable(!screen.canRunAway()) 去问当前画面（每次换画面问一次，战斗结束时再问一次）。同一句 screen.canRunAway()，运行的是当前画面那个类的版本，这就是多态。仗没打完 → true → setDisable(false) → 黑字（4.1 菜单那张图的框 3）。! 和 setDisable 一步一步怎么代进去，见 第 15 章第 4 节。→ 第 5 句

还有一件不用做的事，它是这道题最值得说的一点：逃跑以后，CBattle 和两个 CFighter 没有任何东西再指着它们，直接被丢掉；CMokepon 从来没被改过，所以没有什么要还原（4.1 卷轴那张图的框 4、5）。这靠的是 Project 2 把战斗数值放进 CFighter、让 CMokepon 只读的设计，取代了 Project 1 的 copyMokepon。→ 第 6 句

4.4 一个菜单、三种状态：为什么好扩展

同一个 CGameMenu 对象从头用到尾。三个画面打开它，结果不同，全靠每个画面自己回答 canRunAway() 和 canReturnToMainMenu()：

12

1. 1
   Run away 灰：SelectScreen 没改写，用默认 false
2. 2
   Main menu 也灰：SelectScreen 改写成 false

12

1. 1
   Run away 灰：默认 false
2. 2
   Main menu 可点：默认 true

12

1. 1
   Run away 可点：BattleScreen 改写成 !battle.isFinished()
2. 2
   Main menu 可点：默认 true

CGameMenu.update 里没有一句“如果是战斗画面……”。以后加一个新画面（比如锦标赛画面）也想允许逃跑，只要在新类里改写 canRunAway()，CGameMenu 不用改。这是多态加上开闭原则。

4.5 帮了忙、拖后腿、好不好扩展

4.6 参考答案

中文要点，下面是英文句子。第 1 句讲 Project 1，第 2–6 句讲加了什么，第 7–10 句是帮忙、拖后腿和扩展性（各带 because）。

1. Project 1：菜单在 GameWindow（extends Stage）的 getSelectMenu()、getBattleMenu(...) 里；战斗菜单的 Reset、Restart 直接调用 private 方法；Mokepon 可变，靠 copyMokepon() 复制
   In Project 1 the game menu was built inside GameWindow, which extended Stage, by getSelectMenu() and getBattleMenu(...). In the battle menu, the Reset and Restart Battle items' lambdas called the private GameWindow methods resetSelectScreen() and battleScreen(...), and Mokepon was mutable, so every battle worked on copies made by copyMokepon().
2. 新类 GameMenu：Run away 菜单项（Ctrl+R）调用 navigator.runAway()
   To support running away in Project 2, I moved the menu into its own class GameMenu, whose Run away MenuItem (Ctrl+R) calls navigator.runAway() through the GameNavigator interface.
3. GameWindow.runAway：world.runAway()，再 showScreen(overworldScreen)
   GameWindow implements runAway() by calling world.runAway() and then showScreen(overworldScreen).
4. Overworld.runAway：encounter = null、player.moveBack()、通知 onPlayerMoved()
   Overworld.runAway() sets encounter to null, calls player.moveBack(), which restores the previousPosition field saved by moveTo(), and notifies onPlayerMoved() so that OverworldScreen redraws the map.
5. 能不能点：CGameMenu.update 问 screen.canRunAway()，只有 CBattleScreen 改写
   The item is only enabled when the current screen allows it: GameMenu.update(GameScreen) calls screen.canRunAway(), which returns false in GameScreen and is overridden in BattleScreen to return !battle.isFinished().
6. 不用还原：CFighter 和 CMokepon 分开，逃跑时直接丢掉 CBattle
   Because the battle state lives in two Fighter objects made for this battle only, running away simply drops the Battle and its Fighters; the Mokepon never changed, so nothing has to be reset.
7. 帮了忙：Battle 本来就独立，有日志和 finished；菜单已用 MenuItem 快捷键
   Project 1 helped because Battle was already a separate class with its own log and finished flag, and the menu already used MenuItem accelerators.
8. 拖后腿：菜单焊死在一个大 GameWindow 的 private 方法上；Mokepon 可变
   It made the change harder because the menus were hard-wired to private methods of one large GameWindow and because Mokepon was mutable.
9. 好扩展：新画面只改写 canRunAway()；Overworld.runAway() 已被对话框按钮复用
   The result is easy to extend: a new screen that allows running away only overrides canRunAway(), and the same Overworld.runAway() is already reused by the Run Away! button of the encounter dialog.
10. 限制：CBattle 不知道逃跑；每个新菜单项要在 AGameScreen 和 IGameNavigator 各加一个方法
    One limitation is that Battle does not know about running away, so a rule such as "running away can fail" would need a new method in Battle, and every new menu option adds a method to both GameScreen and GameNavigator.

5. 以后可能的扩展：每一条改哪里

项目说明 projectinfo.md 里列了 8 种“以后可能会要求”的功能。扩展题很可能从这里出。先看总表，考试时找到题目说的那一行，再看下面对应的卡片：

有三个地方“已经会自己长出来”：这些界面是用循环画出来的，循环的是枚举或目录类里的列表，所以加一个新数值、新道具，界面自动多一行或多一个按钮：

1

1. 1
   6 行数值：SelectScreen.createStatsGrid 里 for (Stat stat : Stat.values())

2

1. 2
   3 个道具按钮：BattleScreen.createItemButtons 里 for (Item item : ItemCatalogue.getBattleOrder())

34

1. 3
   只有一行 Mokepon：Player 只有一个 mokepon 字段
2. 4
   道具行：PlayerStatsScroll 里 for (Item item : player.getInventory().getItems())

最可能考、也最难的是 ①。在卷子的 UML 上，它的改动就是一条 containership 线变了：字段名从 mokepon 变成 team，线上的数量（multiplicity）从 1 变成 1..*：

下面 8 张卡片，每张都按“改哪里 → 容易在哪 → 难在哪”写。考试时挑题目问的那一条，照这个格式展开成 5–8 句。

6. 被问到什么，就看哪里

考试时卷子上只有 UML。下面这张表把每个功能对应到类和章节，复习时按题目里的关键词查。

7. 英文答题句型

下面的句型都换成了你代码里的真实名字。考试时把类名和方法名替换掉就能用。

• 谁创建谁：X creates Y in X.m().
  例：Encounter creates both Fighter objects and the Battle in createBattle(inventory).
• 谁存着谁：X holds a reference to Y in its private field f.
  例：BattleScreen holds the Battle in its private final field battle.
• 只是用到，没有存：X depends on Y through a parameter of m().
  例：GameMenu depends on GameNavigator through its constructor parameter; it does not keep it in a field.
• 谁把事交给谁：X delegates Z to Y by calling y.m().
  例：GameWindow delegates running away to Overworld by calling world.runAway().
• 登记监听者：X registers Y as a listener with x.addListener(y).
  例：GameWindow.startGame() registers the OverworldScreen with world.addListener(overworldScreen).
• 多态：The parameter is declared as T, so the call runs the version of the actual subclass.
  例：GameMenu.update(GameScreen screen) calls screen.canRunAway(); only BattleScreen overrides it.
• 说顺序：First …, then …, finally ….
  例：First the player's skill is used, then the enemy's, and finally endTurn() applies lingering damage.
• 说符合某原则：This follows P because ….
  例：This follows the Open/Closed Principle because a new skill is a new subclass of Skill plus one entry in SkillCatalogue, and Battle.playTurn does not change.
• 说不足：One weakness is that …; to fix it I would ….
  例：One weakness is that GameNavigator has seven methods while GameMenu uses only three; to fix it I would split out a MenuActions interface.
• 扩展题的改动：I would add a new class X that extends Y, add a field f to Z, and change Z.m() to call ….
  例：I would add a class Antidote that extends Item, add a method clearEffects() to Fighter, and add Antidote to both lists in ItemCatalogue.

原则和模式的一句话定义，每条配一个你代码里的位置：

8. 常见失分，以及怎么改

Project 1 测验里，两道原则题都写出了定义（Delegation 那题还写了 playTurn()、use() 这样的方法名），丢分集中在交互题和扩展题。原因都差不多：说了“有”，没说“是谁、在哪、为什么”。每张卡片上面是丢分的写法（来自你 Project 1 的答卷，或者常见的错），下面是用这份代码能拿分的写法。

自测