Blog 第二次阶段性总结

前言

就第八、九次题目集而言，知识点主要以类设计为主，并不涉及算法，难度相较上次大大降低。题目主要分为两类：

1. 对输入的数据进行简单的处理并格式化输出
2. 对之前的题目重构，扩展新的功能

因此，本轮题目集的重点是考察对继承与多态的理解与运用，而非直接编程。
本次分析将以两次题目集中的“航空货运管理系统”题目为重点分别进行分析并作出总结。

设计与分析

第一次航空货运管理系统

类图设计

代码分析

• 代码共 543 行，包含 262 条语句，分支语句占比 4.2% ，方法调用语句 73 条。有 8 个类和接口，平均每个类含 8.75 个方法 ，每个方法平均语句数 2.26 。
• 平均复杂度 1.16 ，整体处于较低水平。最大复杂度为 Cargo.getRate() 方法的 5 ，位于 430 行，最大块深度 3 ，最深代码块在 21 行，平均块深度 1.65 。
• 涉及 Cargo、Controller、Customer、Flight、Order、Person 等 7 个类的方法。多数方法复杂度为 1 ，语句数和深度较小。如各 类的众多 getter 和 setter 方法。但 Cargo.getRate() 复杂度 5 ，含 10 条语句，最大深度 3 ；Controller.dealOrder() 复杂度 3 ；Controller.printOrderMessage() 复杂度 2 ，含 15 条语句，最大深度 17 ；Main.main() 复杂度 2 ，含 42 条语句，最大深度 33 ，这些方法相对复杂。
• 深度为 2 时语句数最多，达 135 条；深度 1 有 94 条语句；深度 3 有 23 条语句；深度 4 - 9 + 语句数为 0 。说明代码逻辑集中在较浅深度层次。

总结与心得

通过第一次对程序的实现，对于货物管理系统有了一定的理解并且得到了一个具备一定扩展性的程序。但是程序依然存在许多问题：

• Order类直接与Customer类关联，使得Controller类并没有达到将两者解耦的目的，显得画蛇添足。
• Controller类的设计不合理，超出了单一职责原则，比如getAllCost()方法应该属于Order类。

第二次航空货运管理系统

类图设计

代码分析

• 代码共808 行，72 条语句，分支语句占比 8.3%，方法调用 31 次。包括18个类和3个接口。平均复杂度为1.42，最大复杂度为 3在Main.main()中。
• 继承体系：

1. Customer 分层：Customer（抽象）→ IndividualCustomer/CorporateCustomer，实现Discounted接口（折扣策略）。
2. Cargo 分层：Cargo（抽象）→ NormalCargo/DangerousCargo/ExpediteCargo，实现 Ratable接口（费率计算）。
3. Payment 分层：Payment（抽象）→ Wechat/ALiPay/Cash，多态实现支付方式。

• Visual接口规范Controller的打印逻辑，分离业务处理与视图展示。各子类通过重写getRate()/getDiscount()/payType()实现多态行为，符合 OOP 设计原则。
• 高复杂度方法：
  Main.main()（复杂度 3，语句 12，块深度 4）、
  Controller.dealOrder()（复杂度 3，语句 6，块深度 8）、Controller.printOrderMessage()（复杂度 2，语句 15）。
• 代码块深度分布：
  深度 0-1 的语句占比 76.4%（55 条），深度 4 的语句仅占 1.4%，整体嵌套层次可控，但Main.main()和Controller方法存在冗余分支。

总结与心得

• 类设计缺陷，Main类承担输入解析、对象组装等多重职责，违反单一职责原则。
• Controller同时处理订单逻辑和打印输出，存在拆分的空间。
• 各Cargo子类的getRate()方法存在相似的条件判断逻辑，可通过策略模式统一封装费率规则。

踩坑心得

复杂的输入环节

本次的航空货运管理系统存在的一个显著特点就是要输入丰富多样的数据，即有int型，double型和String型。不仅如此，输入过程也比较复杂。其中一个很麻烦的问题就是Scanner的缓冲区残留问题，在何时使用nextLine()吸收空行是一个问题。
解决方案：
利用单步断点调试，对每一步进行检查，添加在合理的地方添加nextLine()。

仔细读题

• 在题目输出部分中的“订单总重量”指的是计费重量而非实际重量，在阅读评论区后解决。
• 费率计算如下图，但在代码实现的过程忽略了等于的情况，导致代码逻辑错误，后仔细检查代码才发现问题。
  

改进建议

1. 对Cargo的费率计算使用策略模式，定义RateStrategy接口，各子类实现具体策略，消除重复条件判断。
2. 引入工厂模式创建Customer和Cargo实例，避免Main类中的大量switch-case。
3. 拆分Controller为业务逻辑和打印逻辑，降低耦合度。
4. 将/6000、折扣率（0.9/0.8）、费率（35/80 等）提取为类常量。

总结

通过第八、九次题目集“航空货运管理系统”的实践，深入应用继承与多态等面向对象思想。实现了建立基础类结构，二次迭代细化继承体系（如Customer分层、Cargo子类扩展），并且通过实现接口处理折扣、费率计算及支付方式，通过接口分离业务与视图逻辑。但设计中存在Main类职责过重、Controller功能耦合、代码复用不足等问题，部分核心方法嵌套逻辑复杂。
在实践中理解了明确需求细节的重要性。在未来可通过策略与工厂模式优化代码结构，拆分模块职责，提取常量提升可维护性，强化模块化与可测试性设计，从功能实现向架构优化进阶。