题目集8~9的总结性Blog

一、前言

这次题目集8-9的题量都为3题，并且三题的难度我觉得是循序渐进的，比如第一、二题都会给出类的设计图所以我们不需要自己去设计类，只需要实现下题目要求的简单算法就可以了，但是到了第三题航空货运管理系统是需要自己设计类间关系，考虑好哪里需要继承，哪里需要抽象，然后就是还要考虑怎样去使用多态。java与上学期的c语言不同是需要我们用计算思维编译以及设计的，并且是面向对象的，所以我们应该努力去做到单一职责原则、里氏代换原则、开闭原则、合成复用原则，使自己的代码更加合理化才会更有利于日后的工作。

关于这次题目集的知识点：继承是指子类（派生类）可以直接获取父类（基类）的属性和方法，从而实现代码复用，继承分为单继承（一个子类只继承一个父类）和多继承（一个子类继承多个父类），需注意避免因多继承可能引发的 “菱形继承” 等问题。多态则指不同类的对象对同一消息（方法调用）作出不同响应的能力，核心是 “接口相同，实现不同”。多态需通过继承、方法重写（子类重新定义父类同名方法）和父类引用指向子类对象来实现，它增强了程序的灵活性和可扩展性，使代码更易于维护和扩展。

设计与分析

第八次题目集

1.航空货运管理系统（类设计）：
对于第一次接触航空货运管理系统来说，我们需要先将类间关系设计好。所以拿到题目第一件事就是先抽离出对象类，这次的题目有Customer类（客户类），Sender类（发件人类），Receiver类（收件人类），Goods类（货物类），Line类（航线类）。当我们设计好了对象类时，我们就可以观察对象的共性创建出他们的父类，比如我让客户，发件人，收件人都继承于Person类因为他们拥有共同的姓名，电话，地址属性。在做完这些后我们就可以考虑要如何设计功能类了，我设计了一个Agent类去计算每件货物的费用与费率，然后再设计了一个Order类去计算一个订单里所有货物的总价格与总重量，这样将两者分开了有一部分是为了遵循单一原则还有一部分是为了使后续修改与查错更加方便。最后订单的展示就可以在Show这个类中全部展示，这样设计出的代码不仅美观整洁而且做到了单一职责。
以下是我的类图：

2.航空货运管理第一次分析：

根据SourceMonitor分析可知：

1.代码总行数239所以规模并没有很大，语句密度有184条说明我们的逻辑复杂程度可能有些高。

2.分支语句数占比5.4%说明条件语句在整体代码中的占比并不是很高，也从侧面反映了我们的代码能做到单一职责，而不是在一个类里面疯狂的通过if-else来执行下一步。

3.类的接口数为7，说明我们的代码结构并没有特别复杂，设计的较为合理以及算不错的了。而且每个类的平均方法为4.71表明类的功能相对集中有在好好的执行单一职责原则，每个方法的平均语句为5.36也是十分便于维护。

4.最大复杂度为5接近警戒值6，表明存在局部复杂逻辑，可能是show类中的一些比较复杂；平均复杂度低为1.36小于2说明整体结构清晰。

5.代码的最大深度才为3，表明嵌套结构较浅是比较合理的。

第九次题目集

1.航空货运管理系统（继承与多态）
与前一次不同的地方是这次要求了加入继承与多态，而不是简单的几个类了，而且也要求了支付方式不只是唯一的而是支付宝、微信、现金三选一。而且新定义了客户类型与货物类型，这就会导致rate改变并且价格也不是所有货物的总和，而是要更具客户的类型打折。所以除了第一次的那些Customer、sender、show类等等的，我还加上了payMent接口类去负责管理支付方式，加上了CustomerType接口去管理客户类型所以整体上代码比上次会更加复杂，但是整体的系统会更加的流畅与符合现实中的使用。

以下是我的类图设计：

2.代码分析：

1.代码的总行数为339，相较于上一次多了挺多行说明我们的功能也变得更多，但分支占比比例为10.9%没有特别高，说明我们的逻辑分支并不复杂，代码执行路径较少，有利于测试与维护。

2.方法调用语句数为31条，是比较中间的数值，说明我们的代码耦合度并没有特别高，代码功能相对比较复杂充分利用了模块化编程。

3.这次的类接口有12个，比上次多的主要原因在于有三种支付方法，而且还新增了客户类型与货物类型的判断所以功能会更加丰富责任会更细。

4.每个类的平均方法数为8.67说明每个类承担的功能较多，但是还未超过10所以我们还是符合单一职责原则的，只不过是方法可以更优化。

5.最大复杂度有16，最复杂的方法也在Agent类里面，主要原因是因为在Agent类中的Rate（）方法有较多的if-else选项所以会复杂一些，但是呢整体平均复杂度才1.88并没有特别高，所以我们整体的代码是比较符合逻辑的，也十分利于修改。

踩坑心得

1.真的是最简单也是最容易忽视的一点，当我们写的代码过长时我们也许会犯一些很低级的错误，比如写错方法名，忘记将子类继承于父类。所以我们应该努力避免这些低级错误。

2.在动手写代码之前不妨先好好设计类，因为太随意设计的类可能会与我们的实际要求并不相符，这就会导致我们在完成了许多代码后还需要返工不仅浪费了时间还会影响我们的心情。

3.记住抽象类中可以包含抽象方法，也可以包含普通方法。并不是抽象类里面只能由抽象方法构成

4.有些同学可能会忽视@Override的作用，但我们需要重视@Override注解的作用，它能帮助编译器检查方法是否正确重写，有效的提高了正确率。

5.父类中private属性和方法子类无法直接访问，所以我们可以通过getter方法去访问属性。

改进建议

1.建议自己以及同学们在写代码的时候一定要仔细审题一定不能为了快而略读一边题目，就像上面的运行结果都是因为我没认真审题导致输入出问题。

2.我觉得我的Agent类里面其实还有许多方法就比如算Rate这个方法可以单独拆出来做一个类，这样就可以类的复杂度同时也可以更加符合单一职责原则。

3.还有一点就是我感觉还可以在设计一个接口去负责货物类型的管理，这样就可以使货物类更加简单与职责单一，同时也符合Java设计的原则

总结

在这两次的题目集中我都一步步的学习了继承与多态在代码中的一些基础的使用，知道了怎样去设计类间的关系才能使代码变得更加便利，这些都是通过一步步的试错与改善而得来的，所以我十分感激这两周不断努力昨天提升自我编程能力的自己，感谢自己没有在看到那么长的题目之后而放弃思考，感谢自己有耐心去自己设计类间关系自己去琢磨继承与多态中更深一步的内容。下面是一些这次题目的总结。 学习内容上我了解到：

1.较为基础的就是简单的继承与多态的使用，要注意private类型不能被子类直接访问之类的。

2.当存在多层继承和方法重写时，考察方法调用顺序。一般遵循 “从子类到父类” 的查找顺序，优先调用子类重写的方法，若子类未重写则调用父类方法。如在多级继承关系A -> B -> C中，C对象调用方法，先查找C类中是否有该方法，再依次查找B类和A类。

3.静态方法属于类而非对象，不能被重写，也不具备多态性。

需要改善之处：在掌握基础的使用方法之后呢，老师也有在上课时介绍过抽象类与接口，所以我觉得呀，我可以进一步研究抽象类与接口在继承和多态中的应用。这样不仅使我们的代码更加灵活，还降低模块间的耦合度。