第二次Blog作业

关于pta题目集8~9的总结
(1)前言
这两个题目题目集共有六道题目（1.点线面问题重构（继承与多态）2.雨刷程序功能扩展设计3.航空货运管理系统（类设计）4.魔方问题5.点线面问题再重构（容器类）6.航空货运管理系统（继承与多态）），题量不多，其中有四道题目是在上一题的基础上进行第二次迭代，进行重构和拓展。本次所考察的知识点众多以第六题航空管理系统为例，这个航空货运管理系统的作业，主要就是考咱们对面向对象编程的掌握程度。
像单一职责原则，就是让每个类只干一件事，别搞得太杂；里氏代换原则，就是子类能直接替换父类，用接口实现多态；开闭原则是说加新功能（比如新货物类型、支付方式）别改原来的核心代码，方便扩展；合成复用原则是让咱们多用组合关系，少用继承，免得代码耦合太严重；依赖倒转原则就是高层模块别依赖具体类，依赖抽象接口更灵活。

设计模式这块，用策略模式搞定客户折扣、支付方式和货物费率这些可变的部分；输入的时候其实还暗含工厂模式，根据不同输入创建对应的对象；订单和货物的关系又有点组合模式的意思。

Java的核心知识也都考到了，像接口多态怎么写，集合框架怎么用，日期格式怎么处理，还有输入验证和异常处理这些细节。在写代码的时候，还得把类的功能划分清楚，理好数据处理的流程，考虑到以后加新功能也方便。业务上要算对运费，写好订单创建的流程。不过难点也不少，接口设计不好后面扩展就麻烦，对象之间的关系容易搞混，输入验证要是漏了非法数据就会出bug，重复的代码逻辑也得想办法封装复用。做完这个作业，面向对象设计和复杂系统开发的能力都能练到！

从难度方面来说本次题目集的难度并不高，主要考察学生们对于新知识的运用。

（2）设计与分析

行数（Lines）：359
语句数（Statements）：81
分支语句百分比（Percent Branch Statements）：4.9%
方法调用语句数（Method Call Statements）：64
含注释行百分比（Percent Lines with Comments）：7.0%
类和接口数量（Classes and Interfaces）：2
需要增加代码复用率

代码注释方面：含注释行占比仅 5.5% ，过低。建议增加注释，对关键代码段、方法功能、算法逻辑等进行说明，提高代码可读性，方便后期维护和他人理解代码。
代码结构复杂度：从分支语句占比 8.6% 等数据初步看结构不算太复杂，但可结合雷达图中平均复杂度（Avg Complexity）、最大深度（Max Depth）等指标进一步分析。若复杂度较高，可考虑拆分方法、抽取公共逻辑等方式优化，增强代码可维护性。
代码规模管理：421 行代码、175 条语句规模不算小，可梳理代码逻辑，对重复代码进行重构，提高代码复用性，精简代码规模。
类图

（3）踩坑心得
本次题目虽说相较上一次简单，但还是在写的过程中出了很多的问题，不说编写时的一些语法错误，就连最后提交的时候还是修改了好多次才把格式给改对，，但最后没有安排好时间，异常处理这个问题还是没有通过，主要是自己不清楚具体所要测试的点。
典型问题分析

1. 接口设计缺陷
   一开始写CargoType接口的时候，我就想着先把最主要的getRate()方法写出来，赶紧往下写别的功能。当时心里还美滋滋，觉得自己进度挺快，结果到后面要加获取货物描述信息的功能时，直接傻了眼！因为没提前考虑到，只能在接口里加getDescription()方法，然后所有实现类都得跟着改。
   给大家看看我一开始和改进后的代码对比：
   plaintext
   // 初始设计
   interface CargoType {
   double getRate();
   }

// 改进后设计
interface CargoType {
double getRate();
String getDescription();
}
后来实在被搞怕了，就去查资料，按照 “接口隔离原则”，把描述相关的功能拆到Describable接口里，还写了抽象适配器类。虽然改代码的过程超痛苦，但改完之后心里踏实多了，感觉以后再扩展功能应该会轻松点。
2. 多态实现错误
在计算运费那块，我一开始写得特别蠢！居然直接用具体类去判断客户类型，然后写不同的折扣逻辑。当时写完自测还能跑通，我就以为万事大吉了，结果一提交到 PTA 平台，测试用例直接炸了一大半！
给你们看看错误代码，现在看真的觉得自己当时太菜了：
java
// 错误实现
public double calculateFreight(Cargo cargo) {
if (customer instanceof IndividualCustomer) {
return cargo.getBaseFreight() * 0.9;
} else {
return cargo.getBaseFreight() * 0.8;
}
}

后来请教了同学，才知道要用接口引用，把折扣策略通过接口传进去，改完之后就正常了：
java
// 正确实现
public double calculateFreight(Cargo cargo) {
return cargo.getBaseFreight(customer.getCustomerType());
}

改完之后我还专门写了几个测试用例，对比了错误和正确实现的结果，一看表格数据，就知道之前错得有多离谱。

3. 输入验证缺失
   这个问题真的把我坑惨了！我一开始光顾着写核心功能，觉得用户肯定会按要求输入，就没写输入验证。结果自己测试的时候，随手输了个负数的货物重量，程序直接抛出异常崩溃了，当时我都懵了，还以为是哪里代码逻辑写错了。后来在Cargo类的构造函数里加了参数验证，再遇到非法输入就能正常提示错误了，虽然加验证代码没花多少时间，但找问题的过程真的太折磨人了。
4. 工厂模式应用
   工厂模式我是隐式用的，写了个createCargoType方法，根据输入创建不同的货物类型对象。一开始写的时候，还担心这样写不对，后来发现客户端代码和具体实现真的解耦了，再新增货物类型的时候，只需要改工厂方法就行，影响范围特别小
   5.流程图的运用
   画流程图的时候，我也是改了好几遍。给大家看看订单创建和运费计算的流程图，画完图之后，整个流程一下子就清晰了，写代码的时候思路也更顺了![]
   这次作业真的是一次 “痛并快乐着” 的经历。通过踩这些坑，我算是深刻明白了接口设计一定要有前瞻性，多态用对了能让代码超灵活，输入验证再麻烦也不能省，设计模式学好了真的能事半功倍，还有测试用例一定要全面，不然根本发现不了问题。
   6.题目的理解与分析
   在最后的最后，本来欣喜地提交代码却发现连第一个测试样例都没通过，给我紧张死了，输出地金额不一样，仔细算了才发现，这道题根本没用到所讲地折扣，该输出时不用乘以折扣。
   现在回头看，虽然过程很煎熬，但学到的东西比之前做简单作业多太多了。以后再写代码，我一定要把这次的教训记牢，也建议大家和我一样，遇到问题多记录多总结，说不定下次就能少踩点坑

（4）改进建议
经过这次航空货运管理系统的开发，我真是感触颇深，也发现了不少可以改进的地方。咱就从设计、代码和功能这几个方面好好唠唠。
设计层面
接口设计：之前在设计CargoType接口的时候，就因为考虑不周，后面加功能的时候费了好大劲。以后再设计接口，可得多想想未来可能的扩展。比如说，货物类型以后可能会增加特殊属性或者特殊计算规则，那在接口里就可以先预留一些方法，哪怕暂时不用，也比后面再改强多了。就像这次，如果一开始接口里就有获取描述信息的方法，后面也不至于重构那么多代码。
类职责划分：有些类的职责还是有点模糊。比如说Order类，它既要处理订单的基本信息，又要负责和货物、客户这些对象交互，感觉有点太杂了。我觉得可以再细分一下，比如把和货物相关的操作单独拿出来一个类，这样每个类的职责更单一，代码也会更清晰，维护起来也方便。
代码实现
多态的进一步优化：虽然现在用接口实现了多态，但感觉还可以更灵活。比如说，以后如果要增加新的客户类型或者折扣策略，现在的代码可能还是需要在一些地方做修改。我想能不能通过配置文件来管理这些策略，这样以后增加新策略的时候，只需要修改配置文件，而不用改代码，这样就能更好地遵循开闭原则了。
代码复用：有些代码还是存在重复的情况，比如在计算运费和生成报表的时候，有些数据的处理逻辑是一样的。我觉得可以把这些重复的代码封装成一个工具类，这样既减少了代码量，也方便以后维护和修改。
功能拓展
（5）总结

这两次作业就像 “升级打怪”，第一次学会了 “面向对象的基础招式”，第二次逼自己 “组合技能打 Boss”。虽然过程中因为接口设计错误重构了 3 次代码，因为输入验证没写好被 PTA 判错 5 次，但每解决一个问题，就感觉自己对 “如何设计一个‘能扩展、少出错’的系统” 多了一点理解。
最开心的是发现：原来写代码不是 “写完拉倒”，而是 “不断优化”—— 从能跑，到健壮，再到灵活，每一步都有进步空间。接下来想补一补设计模式和单元测试，希望下次作业能少踩坑，多秀操作！