题目集8-9总结性Blog
题目集8~9总结性Blog
前言
题目集8~9共包含5道题目，涵盖继承、多态、容器类设计、复杂业务逻辑实现等核心知识点。题量适中但难度较高，尤其是航空货运管理系统需要综合运用多种设计模式。通过这组题目，深入理解了面向对象设计原则的实际应用，并锻炼了复杂系统的架构能力。
设计与分析
1. 7-1 NCHU_点线面问题重构（继承与多态）
代码结构：
抽象类：Element定义抽象方法display()，Point、Line、Plane为子类。
多态实现：主类通过Element引用调用各子类的display()方法。
优点：符合开闭原则，新增图形类型只需继承Element。
问题：Line类耦合了颜色属性，而Plane也有颜色，可进一步抽象到父类。
SourceMonitor报表：
圈复杂度：Line.display()方法复杂度为8（因包含多个输出语句和计算逻辑）。
代码行数：主类输入处理部分占30行，存在冗余（如多次scanner.nextDouble()）。
关键代码片段：
// Line类计算长度
public double getLength() {
double dx = endPoint.getX() - beginPoint.getX();
double dy = endPoint.getY() - beginPoint.getY();
return Math.sqrt(dx * dx + dy * dy);
}
2. 7-2 NCHU_雨刷程序功能扩展设计
设计模式：
策略模式：WiperSystem接口定义速度计算策略，WiperSystem1和WiperSystem2实现不同业务规则。
职责分离：Lever和Dial类独立管理档位/刻度，Agent协调状态更新。
复杂度分析：
方法复杂度：WiperSystem2.getSpeed()的圈复杂度为10（因多层switch-case嵌套）。
输入处理：主类while循环中的switch-case复杂度为6，导致可维护性下降。
流程图：
graph TD
A[输入操作类型] --> B{操作类型判断}
B -->|1| C[升档]
B -->|2| D[降档]
C --> E[更新速度]
D --> E
E --> F[输出状态]
问题：档位和刻度的范围检查分散在Lever和Dial类中，未统一校验逻辑。
3. 7-1 NCHU_魔方问题
继承结构：
抽象基类：MagicCube封装颜色、阶数、单元形状属性。
子类：CubeMagic和TriangularPyramidMagic分别实现表面积/体积计算。
数学公式验证：
正三棱锥体积：公式(sqrt(2)/12)*a³正确，但代码中未处理浮点精度（如使用Math.sqrt(2)直接计算）。
输入漏洞：未校验阶数是否为正整数，若输入0会导致体积为0。
改进点：将几何计算提取到工具类，避免代码重复。
4. 7-2 NCHU_点线面问题再重构（容器类）
容器设计：
容器类：GeometryObject使用ArrayList
命令模式：AddPointCommand、AddLineCommand等封装不同操作逻辑。
复杂度问题：
主类输入循环：圈复杂度为7（因多条件分支），可通过策略模式优化。
删除操作：未处理索引越界时抛出的异常，仅通过if判断，存在潜在漏洞。
测试用例：
输入：4 3（删除第3个元素）
输出：若容器仅2个元素，操作被忽略。
5. 7-3 NCHU_航空货运管理系统（继承与多态）
业务逻辑：
继承体系：Client派生出个人/企业客户，Shipment派生出3种货物类型。
运费计算：RegularShipment（30元/kg）、ExpressShipment（50元/kg）、DangerousShipment（40元/kg）。
关键流程：
航班载重校验：若订单总重量超过剩余载重，终止程序。
运费计算：总运费 = Σ（货物计费重量 × 费率） × (1 - 折扣率)。
复杂度分析：
ShippingOrder.calculateTotalCost()：圈复杂度为5（因循环和折扣计算）。
输入处理：读取货物信息时需循环解析多字段，易出错。
类图
复杂度分析
问题：ShippingOrder类承担过多职责，违反单一职责原则。
采坑心得
点线面问题：
多态调用错误：初始未将Plane的display()设为public，导致多态失效。
输入格式：未处理颜色输入含空格（如Dark Red），导致scanner.nextLine()截断。
雨刷系统：
档位溢出：WiperSystem2允许档位升到5，但getLeverPositionName()未处理超高速档位，导致输出为空。
状态同步：修改刻度后未立即调用dealSpeed()，导致速度未更新。
魔方问题：
单位错误：误将阶数作为边长直接计算，正确应为阶数 × 单元边长。
浮点精度：使用double计算导致表面积输出误差（如预期1093.50，实际输出1093.4997）。
容器类问题：
索引偏移：删除操作传入index-1，但未提示用户索引从1开始，导致误删。
命令解析：AddLineCommand未读取完整参数（如漏掉颜色），导致Line对象创建失败。
航空货运系统：
载重校验漏洞：未在添加货物时实时更新航班载重，导致后续订单可能超载。
折扣计算错误：企业客户折扣率初始设置为5%，后修正为20%。
改进建议
点线面问题：
抽象颜色属性：将color提升至Element父类，减少重复代码。
输入验证：使用正则表达式校验颜色格式（如不允许空值）。
雨刷系统：
状态模式：将档位/刻度状态封装为独立对象，减少if-else嵌套。
枚举类：定义LeverPosition和DialPosition枚举，增强可读性。
魔方问题：
工厂模式：通过工厂类创建MagicCube实例，隐藏子类细节。
精度控制：使用BigDecimal替换double，避免浮点误差。
容器类问题：
迭代器模式：提供统一的遍历接口，支持多种遍历方式。
输入封装：将解析逻辑移至Command子类，隔离主类复杂性。
航空货运系统：
职责拆分：将订单处理、运费计算、报表生成拆分为独立类。
异常处理：定义自定义异常（如OverloadException），细化错误处理。
总结
学习收获：
设计模式：熟练应用策略、命令、工厂模式解决复杂问题。
调试技巧：通过单元测试和边界值分析定位隐藏漏洞。
待改进点：
代码规范：部分类方法过长（如ShippingOrder.printOrderDetails()），需进一步拆分。
性能优化：大数据量下容器遍历效率低，需考虑数据结构优化。
浙公网安备 33010602011771号