第二次大作业学习

前言

这次大作业是航空货运管理系统的代码学习，因为涉及的主要是对信息的输入与输出所以难度并没有很大，相比较第一次的电梯运行来说在，这次更加注重对类的设计而不是本身的算法，但是通过这次学习还是能学到很多东西的。

第一次迭代

刚拿到题目一看是信息的输出，我就知道这次大作业不会太难，可以比较轻松的写完这个作业，但是因为还是在学习阶段，所以有些语法还不是很清楚，比如那些单一原则，里氏代换一开始没有听过，但是老师要求就是要符合这些规则不然就会进行相应的扣分，所以一开始不敢轻举妄动，在等上课的老师一步一步推进，在上了三天课后，老师已经把规则讲的差不多了，所以我也开始试着完成这个作业，不出所料啊完成的还是比较顺利的，稍微修改了几次就能得到正确答案了。

SourseMonitor分析

---

• 代码行数：414，语句数对我来说还能接受，修改起来还是比较轻松的
• 语句数量：260，同样，没有太多容易修改和阅读
• 分支语句占比：3.1%，占比比较少吧，写的时候刻意减少了分支的使用
• 方法调用语句数量：55，个人感觉还好
• 含注释代码行占比为：0，写的时候比较赶时间害怕写不完，就一直没有写注释可能也是因为写的代码行数比较少所以也没有太影响后面的修改，但是后面肯定会慢慢添加的
• 类和接口数量：8，这些类大部分在题目里面已经给出来了，所以只要跟着老师给的提示写的话就没有太难
• 平均每个类的方法数：8.75，里面有比较多的getter和setter方法，还有构造函数所以比较多
• 平均每个方法的语句数：2.2，比较少在绿色的圈里面
• 最复杂方法所在行号：258
• 最复杂方法名：Product.getRate()，里面判断费率的条件有点多所以比较复杂，而且大量的if也在这里用了
• 最大复杂度：7，比较少啊，在老师推荐的行数之内
• 最深代码块所在行号：15
• 最大代码块深度：3，同样符合老师推荐的深度，因为这次大作业并没有太难吧所以完成的比较顺利

类图

里面有Flight、Person、Stream、Customer、Product、Order、Payment、WechatPay、Alipay九个类

• Fligt：航班类，主要是对航班的基础信息的整合
• Person：一开始没有这个类，写到航班类的时候有收件人和发件人的信息就想着添加这个类，后面迭代的时候感觉没有必要就又删除了
• Stream：物流类，主要是整合全部的信息并进行输出
• Customer：顾客类，包含顾客基本信息
• Product：商品类，有商品的基本信息，还有计费重量也在里面
• Order：订单类，等到一个总价，并与物流类配合
• Payment：支付类抽象的父类，实现支付的方式
• WechatPay：支付类的一个具体类，用于实现微信支付
• Alipay：支付类的另一个具体子类，用于实现支付宝支付

总结

在代码的时候没有考虑好就开始写了，写到Stream类的时候看到要有收件人和发件人信息，当时一想觉得用一个类来添加更好，一开始想加到顾客类里面但是想了一下觉得把顾客改成父类不是很好，就添加了一个Person类，添加了这个类之后觉得顾客类应该也是这个类的子类就试着改了一下，结果发现不好用就独立出来了，后面听老师讲不要为了代码的复用来使用继承关系，所以在下一次迭代的时候就删除了这个三个类，就典型的使用继承是为了代码复用，通过这次大作业，我以后肯定要注意不要随便使用继承关系。因为出现了这些小插曲所以我当时写的心烦意乱的一直在修改这部分，好在后面还是写出来了，这些还只是烦，但是在错误测试的时候一直过不了这个测试点，就一直修改，一直显示格式错误，因为是格式错误所以我也就没有过多的在意毕竟代码的整体算法没有问题，后面问了室友才知道是老师给的文字里面对错误信息的空格没有给好，一修改果然就过了，但是也快到截止时间了，好在有惊无险。

第二次迭代

SourseMonitor分析

---

• 代码行数：533，语句数对我来说还能接受，修改起来还是比较轻松的
• 语句数量：278，同样，没有太多容易修改和阅读
• 分支语句占比：6.8%，占比比较少吧，写的时候刻意减少了分支的使用
• 方法调用语句数量：85，个人感觉还好
• 含注释代码行占比为：0，写的时候比较赶时间害怕写不完，就一直没有写注释可能也是因为写的代码行数比较少所以也没有太影响后面的修改，但是后面肯定会慢慢添加的
• 类和接口数量：10，这些类大部分在题目里面已经给出来了，所以只要跟着老师给的提示写的话就没有太难
• 平均每个类的方法数：6，里面有比较多的getter和setter方法，还有构造函数所以比较多
• 平均每个方法的语句数：2.97，比较少在绿色的圈里面
• 最复杂方法所在行号：240
• 最复杂方法名：DangerousProduct.getRate()，里面判断费率的条件有点多所以比较复杂，而且大量的if也在这里用了
• 最大复杂度：7，比较少啊，在老师推荐的行数之内
• 最深代码块所在行号：32
• 最大代码块深度：4，同样符合老师推荐的深度，因为这次大作业并没有太难吧所以完成的比较顺利

类图

• Fligt：航班类，主要是对航班的基础信息的整合
• Stream：物流类，主要是整合全部的信息并进行输出
• Customer：顾客类，包含顾客基本信息
• Product：商品类，有商品的基本信息，还有计费重量也在里面
• Order：订单类，等到一个总价，并与物流类配合
• Payment：支付类抽象的父类，实现支付的方式
• WechatPay：支付类的一个具体类，用于实现微信支付
• Alipay：支付类的另一个具体子类，用于实现支付宝支付
• DangeousProduct：商品类的一个具体子类，主要是危险物品的信息，比如费率之类的
• Expedite Product：商品类的具体子类，加急商品的信息
• IndividualCustomer：顾客的具体子类，个人购买的类
• Corporate Customer：顾客的具体子类，合作购买的类，打折力度与个人购买不同
• CashPay：支付类的具体子类，实现现金支付
• Confirm Type：工厂类，决定每一个父类产生的子类类型，辅助主函数的进行

总结

这次迭代需要把顾客类抽象，添加现金支付，商品分为普通，加急，危险三个等级，其费率不同，需要进行不同的费率运算，在修改这次的代码时，我是直接在上次的迭代代码基础上修改的，在更改商品类的时候自己添加了两个类并继承了原来的商品类，原来商品还是能正常工作，不知道这样符不符合多态的要求，但是我觉得这么写的话没有什么问题，而且修改起来比较简单，所以就直接添加了，还需要添加现金支付，这个也简单直接添加一个现金支付的子类并继承原来的Payment类就好了，修改也是非常的迅速，还要修改顾客类为抽象，并添加两个类的分类，这样就有点麻烦了，我先要把顾客里面原来的方法进行修改，还要添加新的类，改起来比较麻烦，但真正麻烦的不是这些小类的修改和添加，真正难改的是main函数的修改，因为之前只是输入一个货物所以不涉及循环的使用，但是，这次却需要用到循环在输入里面，最难的是对于对象的创建，放到循环里话，idea会报错，因为不一定会进入这个循环，然后我就放在了外面，但是之前的输入因为是使用了Person类去写，就一直要去改，这里是花费时间最久的地方，因为上一次的错误搞得我在这次修改很难受，只能说慢慢进步吧。

学习总结

代码迭代还是太紧凑了，上一次有错误，就会导致下一次修改很麻烦，一环扣一环，还好这次的大作业并没有过多的考查算法，让我能有更多的时间来修改那些第一次写代码留下来的不好之处。通过这次学习我认识到不能为了代码复用来使用继承关系，不然会对后续修改造成很大的麻烦，还有开闭原则的重要性，因为使用了父子类，我明显能感受到修改代码的便捷性，相较于上次大作业修改功能呢需要到具体实现方法的地方更改而言，使用了继承方法在添加功能上有着天大的好处，只需直接添加一个新的类就可以完美添加新功能，非常的方便。并且通过这次的学习，我认识到真正重要的是算法的提出而不是对于语法的使用，类的分类也是非常重要的，合理的类分别能够使得功能更加集中，分类的标准是相同的功能放在一起。里氏原则则是对继承关系的规范，在使用子类的地方可以用父类去替换他，这样在代码修改时可以非常的方便，开闭原则也是针对修改的对扩展开放允许通过新增代码（如添加新类、新模块）来扩展软件的功能，应对新的需求或变化。在不修改原有代码的基础上，灵活扩展系统能力。当需求变化时，尽量不修改已有的成熟代码，避免因修改导致原有功能出现 bug 或稳定性问题。保护已有代码的完整性和稳定性。