java题目集之货运系统

作者：曾建东 | 南昌航空大学 软件工程大一
时间：2025‑05‑25

---

1. 前言｜我对“货运系统”的误解

这次项目刚看到题目我又上头了：

“个把类封一封，Scanner 读一读，不就完事了？”

然后我就……又一次给自己挖了个坑。

这玩意不但要设计继承和多态，还得处理一堆输入流程、货物策略模式、计费算法、客户折扣、超重判断……最后还得输出到小数点后一位精度，PTA 一顿爆红，SourceMonitor 一堆红条，瞬间从“我能写”跳转成“我能改”。

于是，我又开始造轮子，又开始交白卷，又开始怀疑人生。

---

2. 类设计与分析｜这回终于真用了继承和多态

这次系统比电梯项目更具“企业系统范儿”，我真的第一次认真画了 UML 类图，然后边看边写类。先放最终类图 ▼

2.1 多态使用：货物类型 × 运费计算策略

三个货物类型：普通 / 急件 / 危险，对应三个策略类，统一继承 RateStrategy 接口。

RateStrategy strategy = RateStrategySelector.getStrategy(productType);
float fee = strategy.calculateRate(chargeWeight);

策略选择器一把梭，完美解耦业务逻辑和计费规则，虽然简单，但真的用上了“多态的正确姿势”。

2.2 继承使用：Customer / People / Payment

• People 抽象出姓名、电话、地址，被 Customer、Giver、Receipist 复用；
• CustomerType 和 ProductType 枚举类型拆开，代码更安全也更清晰；
• Payment 是接口，子类实现了微信/支付宝/现金支付方案，为未来拓展留了口子。

用完接口我才发现：之前写死的 if-else 逻辑其实早该扔。

---

3. 源码统计｜这份 Main.java 又超 400 行了

指标	数值	解读
Lines	482	这不是“Main”了，是“大统筹”，可以考虑按包拆了
Classes and Interfaces	12	类确实多了，但说明设计变复杂了
Average Complexity	2.33	平均复杂度尚可，但下边那个方法你看……
Name of Most Complex Method	Controller.recept_twoList()	圈复杂度：20，嵌套深度 8，是时候拆子函数了
Method Call Statements	95	调用密度大，说明对象之间耦合紧密
Percent Lines with Comments	0.4%	呵呵，我自己都看不懂自己的代码了……

---

4. 踩坑清单｜能跑是一回事，跑对又是另一回事

坑号	关键词	真相	修复方式	时间
01	ProductType异常	输入时没有统一转大写，直接 valueOf() 就炸了	加 .toUpperCase()	10min
02	重复构造策略类	每件货物都构造一遍 RateStrategy，很浪费	用 Selector 单例分发	30min
03	航班负重判断	写完后才发现超载检测写迟了，用户输入都输完了才报错	提前判断 orderWeight > maxLoad	20min
04	支付类接口丢失	pay() 什么都没写还通过了编译，但后期要调试时懵了	加日志占位 or 写假实现	15min
05	输出小数精度	小数点后一位四舍五入忘了 *10 /10.0f 的顺序	统一用 Math.round(...*10)/10.0f	1h

---

5. 改进与展望｜从“写对”走向“写好”

✅ 当前我做对了的：

1. 类图先行，写得更顺了。
2. 策略模式代替 if-else，代码不再臭长一坨。
3. 整合打印逻辑，用 printOrder() 封装成清爽一法。

⚠️ 还有很多可以提升的点：

目标	为什么
把 OrderManage 拆成服务类 + 工具类	现在 addOrder() 太胖，超过 120 行了
把输入构造提取成 InputParser 类	保证数据源和业务逻辑分离
给每个类写单元测试	目前完全无覆盖率，怕改动
优化输出格式 + 增加格式校验	现在输出“差点意思”，并且没有做输入异常处理

---

6. 写在最后｜这次我是真的用了 OOP 的皮和骨

这一单项目做完，我终于理解了**“继承和多态”不是语法糖，而是设计思想的具体化**。如果没有事先规划类结构、接口、策略，我估计又会像写电梯那次一样，一发 if 写成无底洞。

这次我真正：

• 学会了怎么根据业务场景去抽象类；
• 学会了先画图、后写代码的逻辑流程；
• 意识到主类 Main 不该成了“万能大管家”；
• 第一次写完程序还顺手写了单元测试。

虽然依然存在结构不够清晰、代码密度过大、复杂度过高等问题，但我觉得我从“把事做完”逐渐转向“把事做好”了。

---

尾声：
货运系统项目告一段落，我感觉自己的面向对象编程终于摸到了“应用”的门槛。现在的我，再回去看电梯项目，已经能明确指出自己当时的设计缺陷——这就够了。