第二次Blog作业

一、前言：
本阶段的题目集主要考察类设计，重在提高对类与类之间的关系、继承与多态、七大原则的理解运用能力，题量与第一阶段题目集一样，难度相较第一阶段题目集略简单，但是需要构思设计好类与类之间的关系，否则也是不免增加繁琐的问题。两次题目集的前两题都是对先前题目的迭代，有了更加细致的类与方法的划分，但是难度不大。最后一题则是两次迭代，考验类设计的能力。总体来说本阶段题目集难度低于第一阶段。

二、设计与分析：
{1}题目集08 7-3 NCHU_航空货运管理系统（类设计）
第一次迭代代码的SourceMontor报表内容和PowerDesigner相应类图如下：


根据报表内容，共302行代码，最大复杂度6，平均每方法语句数5.38，部分方法如 Object.calculateFreight()逻辑复杂，需通过提取子方法简化。方法调用52次，模块间交互频繁，反映出模块间交互紧密，需关注耦合度的影响。
整体方法规模较为适中，但部分方法的复杂度和深度存在差异。主方法的复杂度为6，是所有方法中最高的，代码深度达到4层。这表明主方法承担了过多的功能，逻辑相对复杂，而其他大部分方法的复杂度为1，说明这些方法功能较为单一，结构简单，符合良好的设计原则。代码注释比例为0%，说明仍然没有养成添加适当注释的习惯，影响后续的对代码的理解，也为第二次迭代时重读代码添加了困难。
在类设计上，首先使用了抽象与继承，例如通过Payment抽象类和其子类的设计，将支付功能进行抽象和封装，提高了代码的可扩展性和可维护性。其次遵循了单一职责原则，例如Flight类专注于航班载重管理，Object类专注于货物相关计算，Order类负责订单的整体处理，这有利于代码的复用和维护。
在后续优化上，可以在Order的订单生成（generateOrderReport）、Object的货运计算（calculateFreight）、Flight的载重控制（canCarry）处添加相应的注释，说明业务规则。其次可以简化Object.calculateFreight()，通过模块化设计如将费率计算方法进行封装降低复杂度。也可以使用新学习的接口封装Object，Order依赖接口而非具体类，降低耦合度。

{2}题目集09 7-3 NCHU_航空货运管理系统（继承与多态）
第二次迭代代码的SourceMontor报表内容和PowerDesigner相应类图如下：


根据报表内容，共332行代码，最大复杂度14，说明方法逻辑复杂。平均每方法语句数5.92，说明仍然有部分方法初始化逻辑冗长，可将其拆分为多个子方法，提升可读性。方法调用70次，比第一次的迭代代码更多，说明模块间交互更频繁，需检查是否存在不必要依赖。
相比于第一次迭代代码，第二次新增了客户类型与折扣机制以及货物类型与费率的细分，同时扩展了支付方式
首先扩展了Customer类，新增了customerType属性用于区分客户类型，同时添加了折扣逻辑，在方法Order.getDiscountRate()中根据客户类型应用不同折扣。其次在Cargo类中新增了type属性（Normal/Dangerous/Expedite），根据不同的货物类型确定费率。新增了现金支付（CashPay）实现Payment接口，支持三种支付方式（微信/支付宝/现金）。同时在主方法中通过用户输入指定支付类型，使用switch-case创建对应支付对象，可以动态选择支付方式。

三、采坑心得：
本次迭代重在于类设计，在最开始进行构思设计时未考虑周全，部分类的职责不明，对后续的代码实现制造了阻碍。同时在第一次迭代的代码缺少相应注释，为第二次迭代尝试理解修改代码时创造了麻烦，同时有些命名仍然不能很好反映对应的职责，也造成了一定阻碍。

四、改进建议：
1.在编程中添加适当注释，例如添加有关费率计算方法的注释，便利后续对代码的理解和迭代。
2.在类设计时考虑不周，有时在实际实现中才意识到设计的不合理性，浪费了时间精力。后续要在遵守七大原则的前提下进行构思设计，增强类设计的合理性。

五、总结：
通过本阶段题目集我学习了继承与多态、抽象类的使用，增强了对依赖倒转，里氏替换原则的理解和运用。同时也学习到了接口，但是运用不熟练，在下一阶段的学习中需要加强练习。也要在后续学习中加深对七大原则的理解和实际应用，例如开闭原则在继承中的体现。

六、建议：
增加实际编程的环节，加深学生对知识点和编程原则的理解。