题目集8~9的总结性Blog

1. 前言

知识点总结:

这两次题目集主要还是锻炼我们的类设计能力,其中有一些题目是扩展了之前的题目,加了一些条件,改了一些判断方式,但是代码的大体逻辑不变,让我们深刻认识到了遵循设计原则的重要性,如开闭原则和依赖倒置原则可以让我们在较少的改动下完成这次题目.

知识点有用到继承,多态,集合等,这次的9题目集的第三题也让我们意识到了,集合中的多态性可以怎么运用来简化代码.

两次题目集都是侧重于锻炼我们的类设计能力,但是题目集9更侧重于系统扩展.

题量与难度：

两个题目集的题量都是3道,题目集8是第一道点面设计与第二道雨刷器功能的扩展,重构,第三道的航空货运管理系统的初次设计;题目集9是第一题的点面设计的魔方类的设计与第二题的点面设计,第三题的航空货运管理系统需求改变. 两次题目集都是呈现难度递增的趋势.

2. 设计与分析

题目集8：

源码分析：

类图

一、核心类功能

类名	功能简述
Customer	存储客户基础信息（姓名、电话、地址）
Cargo	描述货物属性（名称、尺寸、重量），计算计费重量（体积与实际重量取最大值）
Flight	存储航班信息（航班号、载重限制）
OrderDate	存储订单日期、收发件人信息（订单号、姓名、地址等）
FreightCalculate	根据货物重量计算运费费率和金额（继承自抽象类）
Order	整合订单全量信息，打印客户详情与货物明细（继承自抽象类）
Main	程序入口，负责输入数据、创建对象、校验逻辑（如航班载重）

二、类间关键关系

继承有

AbsCalculateFreight <|-- FreightCalculate
AbsOrder <|-- Order

组合有

Order *-- Flight : 包含
Order *-- Cargo : 包含多个
Order *-- OrderDate : 包含
Order *-- Customer : 包含
Order *-- FreightCalculate : 包含多个
FreightCalculate *-- Cargo : 依赖货物数据

复杂度分析

1. 文件太大，结构混乱

416 行代码全放在一个文件里，虽然包含 9 个类，但应该拆分成多个文件（1 个类 1 个文件）。
0% 注释，时间久了自己都看不懂，尤其是复杂方法 FreightCalculate.calculateRate()。

2. 部分方法逻辑较复杂

最复杂的方法 calculateRate()复杂度=5（一般超过 5 就要优化），建议：
- 拆分成多个小方法
- 用 switch或策略模式替代 if-else
最深嵌套 3 层（第 23 行），可以尝试减少嵌套，用 return 提前返回。

3. 类设计可能不合理

平均每个类有 7.11 个方法，有些类可能做了太多事情，违反单一职责原则.

设计亮点与不足：

代码类的设计较为合理,可扩展性较好,虽然每个类看似方法都挺多,但有许多Getter,Setter方法,没有违法单一职责.

但我为了方便将所有代码全部放进一个文件里导致文件太大,而且也没有在一些关键地方添加注释让之后的阅读难度较高.

代码不算太糟，但如果不拆分文件和加注释，以后维护会很痛苦！

心得：

在计算订单总重量(kg)时,下意识以为就是实际的重量和,但题目的测试是用计费重量计算的导致我一直没有发现问题,浪费了许多时间,后来自己突然发现后才看到评论区已经有人说了这个问题了😑,让我意思到与同学多讨论可以减少这种没有意义的问题.