第二次Blog作业总结分析——航空货运管理系统

（1）前言：

总结两次题目集：

题目集8题量为3道，第一题为点线面问题重构，难度为中等。这道题在“点与线（类设计）”题目基础上，对题目的类设计进行重构，以实现继承与多态的技术性需求。

第二题为雨刷程序功能扩展设计，难度为中等。这道题在给定的汽车手动风挡玻璃雨刷程序的基础上，对程序进行重构（Refactoring），使得程序可以对功能进行扩展。本题有两套雨刷操作系统，旨在实现功能的扩展，考查类的封装、继承与多态，使用抽象类和接口实现两套雨刷系统之间的切换选择。

第三题为航空货运管理系统，难度为中等。本题重点考核面向对象设计原则中的单一职责原则、里氏代换原则、开闭原则以及合成复用原则。

题目集9题量为3道，第一题为魔方问题，难度为较难。本题主要考查继承与多态的运用实现正方体魔方和正三棱锥魔方表面积和体积的计算。

第二题为点线面问题再重构，难度为较难。本题在“点与线（继承与多态）”题目基础上，对题目的类设计进行重构，增加容器类保存点、线、面对象，并对该容器进行相应增、删、遍历操作。

第三题为航空货运管理系统，难度为较难。本题在上次题目集的基础上对用户类、支付方式、货物类进行了扩展，重点考核面向对象设计原则中的单一职责原则、里氏代换原则、开闭原则以及合成复用原则、依赖倒转原则。

 

（2）设计与分析

第一次航空货运管理系统：

PowerDesigner的相应类图：

SourceMontor的生成报表内容：

 

分析：该题提交的代码方法数适中，最大复杂度为5，较为安全，易于理解和维护。平均复杂度为5，质量评估中等，部分函数可能较复杂，耦合度较高，职责可能不单一，可选择性优化。代码最大块深度为3，较为安全。平均块深度为1.90，质量评估中等，部分代码嵌套略深，影响可读性与维护成本。代码分支语句数占总语句数小于20%，主要是顺序执行，缺乏必要逻辑判断。

 

第二次航空货运管理系统：

PowerDesigner的相应类图：

 SourceMontor的生成报表内容：

 

分析：该题提交的代码方法数适中，最大复杂度为12，比第一次代码风险高，更难理解和维护，需要更多测试用例才能覆盖，更容易隐藏潜在bug，修改时容易引入新问题，建议重构。平均复杂度为3.90，比第一次代码逻辑简单，可维护性高。代码最大块深度为4，比第一次代码质量差，代码复杂度高。平均块深度为2.01，比第一次代码质量更低，部分代码嵌套略深，影响可读性与维护成本。代码分支语句数占总语句数小于20%，但比第一次代码占比高，拥有适度条件逻辑。

总体来看，第一次代码安全性较高，复杂度不高较为简单，第二次代码复杂度明显提高，但复杂度超过安全值，有一定的风险导致可维护性差，可见第二次代码还存在大量潜在问题。第一次代码采用面向过程的编程风格，业务逻辑高度耦合在Main类中，缺乏合理的分层设计。所有运费计算和业务规则都硬编码在方法内，导致扩展时需要修改多处代码，违反开闭原则。类型系统简单，没有充分利用继承和多态特性，客户和货物类型通过条件语句区分，增加了维护成本。第二次代码通过抽象类和接口建立了清晰的层次结构，采用策略模式实现差异化的运费计算，符合开闭原则。新增的Payment接口和Goods抽象类构成了稳定的抽象层，使得支付方式和货物类型可以独立扩展。显示信息被抽离到专门的showOrder类，符合单一职责原则。类型系统通过Individual/Corporate客户分类和Normal/Expedite/Dangerous货物分类，使业务概念更加清晰。两次迭代体现了从"能用"到"好用"的转变。

 

 

（3）踩坑心得

首先是类的设计，一开始并不知道应该设计哪些类，对于货物的处理设计出订单类，但是没有想到会有多个货物的订单，也就没有考虑到货物类和订单类是组合的关系。

然后是Scanner的nextLine()和next()混用导致输入错位，但是一开始是全部使用nextLine()输入字符型总是错误，后来才全部都换成next()。

当然第一次题目设计的还是有不合理的地方，因为第一次题目没有选择支付方式的要求，订单里也没有这个选项，所以第一次代码写的关于支付方式的类是没有多大意义的，有一定的逻辑错误，因为paymentChoice硬编码为0，永远选择微信支付。

在两次代码Goods类都同时承担了数据存储和运费计算职责，可能违反了单一职责原则，但是我自己不是特别清楚，也不知道这些应该放在哪里，所以就没有改动。

在提交时总是发现异常测试答案正确，而正常测试却是答案错误。后来发现在输出订单时输出格式出错，我使用的是空格，而题目给出的示例使用的是\t。

通过这两次作业，我深刻体会到良好的面向对象设计不仅能提高代码质量，还能显著降低后期维护成本。特别是在处理复杂的业务规则时，合理应用设计原则可以使系统更灵活、更易于扩展。我深刻认识到，好的系统不仅需要实现功能，更需要考虑可维护性、可扩展性和健壮性。

（4）改进建议

在写代码前先设计好结构，先画个简单的类图，想清楚每个类是干嘛的；把运费计算、订单处理这些功能分到不同的"小房间"（模块）里；提前想好哪些地方以后可能会改（比如支付方式）。在实现代码时我自己对于单一职责原则，依赖倒转原则，开闭原则，里氏代换原则的概念比较模糊，导致有部分地方违反了这些原则而我却不自知。在以后的编码过程我应该加强对各种编码原则的理解和实现。还有对于类的职责设计应该更加明显和分层，减少模块间耦合。对代码建立异常处理机制，对边界数值进行校验和检查，加强代码的健壮性。后期我将学习利用工厂模式管理对象创建，将客户、货物等对象的创建逻辑集中到工厂类中，避免构造逻辑分散在各处。当新增类型时，只需扩展工厂类而不需修改业务逻辑代码。

（5）总结

总的来说，这两次题目集难度比之前要大，收获也更多。特别是在类的设计上更加灵活和复杂，考虑的需求更多。这两次题目集的大多数题目都是在之前的写过的题目上完成进一步迭代，对类的功能进一步扩展。通过这两次航空货运管理系统的开发实践，我收获了很多宝贵的经验。首先深刻理解了面向对象设计原则的重要性，特别是单一职责和开闭原则的实际应用。第一次作业让我认识到，把业务逻辑分散在各个类中会导致维护困难，而第二次通过抽象类和接口的合理运用，使代码结构清晰了很多。在技术层面，我学会了使用继承和多态来避免重复代码，但也暴露出需要加强的方面——复杂业务场景下的异常处理策略。最需要深入研究的是如何平衡设计的复杂度和实用性，编写既符合规范又易于理解的代码。

这些经验让我明白，好的代码不仅要实现功能，更要考虑可维护性和扩展性。后续我会通过更多实践来提升代码质量意识，保持持续学习的心态，在实践中不断反思和改进，成长为优秀开发者。