第二次阶段性OOP题目集总结性Blog

前言：

• 基础题目训练说明
  • 第一次基础题目有两道，题量较少，通过对之前题目的进一步扩展，考察知识点主要是1.类的封装、继承、多态2.抽象类3.接口。题目主要考查了学生对代码结构和可扩展性优化的能力。难度为⭐⭐
  • 第二次基础题目有两道，题量较少，考察知识点主要是1.继承和多态以实现代码的可扩展性2.容器类和其基本方法的使用如list.add(),list.get()等等。3.数学知识的灵活使用，学生应当先求解出几何体体积公式再进行编码。举了生活中常见例子魔方类，要求读者能看懂UML类图，理解并掌握依赖倒置原则（DIP），实现类依赖接口或抽象类 而抽象类或接口不依赖于实例。难度为⭐⭐⭐。
• 迭代题目训练说明
  • 第一次迭代题目主要考察学生能否从冗长的题目中获取关键信息，输入输出以及打印的方式等等.考察知识点主要是类的合理设计，继承和多态在设计过程中的合理运用，题目要求代码符合基本设计原则中的：单一职责原则（SRP），里氏代换原则(LSP)，开闭原则(OCP)，合成复用原则（CARP）。难度为⭐⭐⭐⭐。
  • 第二次迭代题目集考察知识点主要是要求实现求可扩展的用户类、支付方式类、货物类。依旧要求遵循五个基本设计原则，题目新增加了货物的类别，客户的类别，以及支付方式的选择，让学生能在设计的过程中更好的理解遵守设计原则的重要性。难度为⭐⭐⭐。
    上面的要求总体来说就是要求学生理解并掌握运用设计基本原则，能将理论融合到航空货运管理系统等题目中去。第二次迭代就是在第一次的基础上增加了类的种类，让学生意识到需求时可能随时发生变化的，所以在编码阶段代码的可复用性和可扩展性就显得较为重要。下面分别在两次迭代作业中分享本人的心得。😊

第一次NCHU_航空货运管理系统（类设计）

• 题目需求

• 要求对航空货运管理系统进行类设计，编写程序需要从键盘依次输入填写订单需要提供的信息，然后分别生成订单信息报表及货物明细报表，核心要求为遵守单一职责原则（SRP）、里氏代换原则(LSP)、开闭原则(OCP)以及合成复用原则(CRP)四个java设计原则。

1.设计与分析

1.类图设计

点击查看类图设计

设计解释

• 将共同属性抽取出来后设计的父类有 person，pay。
• 继承父类person类的有recipent，sender，customer类。继承pay父类的有wechat，airpay类。剩余类为goods(货物)类，goodlist（货物链表类），order（订单类）。
• 为了实现在不同支付方式中金额倍率计算方式的不同设计了接calculateTate。为了打印寄件人，收件人，货物等信息设计了接口showobject再在各个类中实现自己的接口打印方法。
• 在设计订单类的基础上还增加了订单明细类，即Orderdisplay类，更加符合实际生活中购买货物的日常。

2.SourceMontor报表

点击查看分析报告图示

- 从图上看，%Comments（平均代码注释量）明显较少，不在优质代码范围之内。由于此次航空货运管理系统主要考察类设计的合理性，所以本人的 Max Complexity(最大圈复杂度),Max Depth（最大嵌套深度）,Avg Complexity（平均圈复杂)等反应代码逻辑处理和职责单一质量的情况情况都较好。

点击查看具体方法复杂度

3.思路解释与分析

1. 在设计过程中本人先明确题目需求和类的需求，先观察打印信息的共同属性，设计了person等父类，再分别衍生出子类。在明确思路后依照设计类→输入方式设计→优化细节打印信息，后面能较为顺利的解决此题。

2.踩坑心得

• 踩坑：在看见题目后本人认为已经大致理解题目意思边开始照本宣科式的开始设计一个个题目中有的类，在快设计完成后才发现其实很多类都拥有人的共同属性，完全可以提取出一个父类，于是只好推翻重来浪费了较多时间。

---

• 心得：在以后的迭代训练中一定要先做好设计，设计完成后已经完成了90%，在开始编码这样思路会清晰很多，也不会导致代码推翻重来的情况，在设计时遇到思路纠结的地方就一定要想清楚，规划好而不是一边编码一边设计，这样很有可能那个纠结的点就导致你要推翻许多代码重新来过。
• 这里是本人设计完成后提交时遇到的问题

1. 在IDEA中输入pta题目给出样例的时候，还没有按下回车就直接打印结果，而结果也不是自己预期的。🎗️致错原因及解决方案：混用sc.nextInt()...和sc.nextLine()，方法导致读取到空行，解决方案就是在sc.nextInt()这类方法后面补充一个sc.nextLine()消除空行。但此方法较为麻烦还有一个更加便捷的解决方法就是使用sc.next()来统一输入方法避免此问题发生。
2. 在调试完成之后提交依旧错误，但是给出样例测试点已经能通过，所以本人又耗费时间去查看逻辑错误，但是并没有查找出来浪费了较多时间。🎗️致错原因及解决方案：其实是本人不够细心，在pta平台中不一样的输出会给一个加重行区别，因为习惯使用英文冒号:,但样例输出的使用的是中文冒号：。计算倍率方法使用错误但是碰巧能通过所给样例所以在能通过样例，但是还是答案错误的情况下，纠正代码时候应当自己合理编写测试数据这样能比光看代码查找错误更加准确方便。

3.改进建议

• 从Kiviat图中可知代码注释过少，应当适量增加代码注释量，这样不但利于他人阅读和扩展自己代码，也有利于自己代码的阅读，便于在迭代过程中能较快的找回上一次自己的思路而不是要重新阅读回忆，这样可能存在偏差，效率也较为底下。

第二次 NCHU_航空货运管理系统（继承与多态）

• 题目需求

• 对上一次的航空货运管理系统进行进一步的需求升级，要求实现可扩展的类：用户、支付方式、货物。在输入方式上为了体现继承与多态和代码的可扩展性增加了个人用户和团体用户，危险货物，普通货物和加急货物，题目要求了可选择的客户类别和货物类别要求对应不同的货运方式，计算方式等等。需要从键盘依次输入填写订单需要提供的信息，然后分别生成订单信息报表及货物明细报表以更加符合现实生活中的需求。题目依旧需要符合单一职责原则（SRP）、里氏代换原则(LSP)、开闭原则(OCP)以及合成复用原则(CARP)java核心四个设计原则。

1.设计与分析

1.PowerDesigner类图

点击查看类图设计

设计解释

• 在第一次的基础上使得Customer（顾客类）也成为父类从而派生出IndividualCustomer（个人类），和CoporateCustomer（团体类），进一步更好的实现了代码的可扩展性也符合了题目需求。
• 声明goods（货物类）为父类从而派生出Normalgood（普通货物类），Expeditegood（加急货物类），Dangerousgood（危险货物类），再通过父类CalculateTate类派生出不同的计算倍率的方法，实现了程序的可扩展性。
• Pay抽象类，定义支付方式。下有实现类：Alipay（支付宝）、新增Cash（现金）、WechatPay（微信支付）。体现策略模式，扩展可新增支付方式。
• 关联（Association）：如Order与Goods、Customer、Sender/Recipient的关系。
• 继承（Generalization）：如Customer和IndividualCustomer/CorporateCustomer、Person和Sender/Recipient、Pay。
• 实现（Realization）：如不同支付方式实现Pay接口。
• 聚合（Aggregation）：如GoodList与Goods的关系（GoodList可包含多个Goods，但Goods可独立于GoodList存在）。

2.SourceMontor报表

点击查看分析报告图示

• 由分析报告可知本人在第一次代码的前提下适当增加注释后，%Comments（平均代码注释量）已经基本达到优质代码区域，说明此代码提升代码可维护性，能快速定位问题，减少沟通成本，在较长时间后也易于扩展。而 Max Complexity(最大圈复杂度),Max Depth（最大嵌套深度）,Avg Complexity（平均圈复杂)等依旧较低，处于优质代码范围之内。

点击查看方法具体复杂度

3.思路解释与分析

• 在第二次迭代作业的设计中，本人先明确了相比于第一次增加了哪些需求，然后再根据现有的代码修改和微调，使之更加符合代码规范，java设计原则以及题目需求，在实际编码的过程中运用继承和多态，以加深对其的理解。而在输入方式上采取sc.next()统一输入方式使代码更加容易阅读。

2.踩坑心得

• 踩坑：由于在第一次迭代过程中本人并没有给代码加上关键注释而且在开始编码第二次迭代作业开始较晚所以刚拿到题目对于自己上一次的思路与设计并不清晰而是重新阅读题目以及要求才逐渐读懂思路重新编码。在已经能通过测试样例的时候本人并不敢提交，再仔细阅读一遍题目后才发现硬性新增加的要求，所以又只能重新编码直至完全符合要求后才敢提交，浪费了较多时间。
• 心得：在每次做迭代作业时候应当添加适量的代码注释，这样才易于自己第二次迭代过程中能较快的找回设计思路。在相比于第一次的迭代设计中应当先阅读清楚新增的要求有哪些而不是急于完成编码，这样才对自己设计能力有所提升。

3.改进建议

• 虽然代码复杂度，和平均代码注释量都基本符合要求但是在编码过程中本人还是应当抱着学习提升的心态去完成每次的迭代作业。改变心态，逐步提升，减少对ai的依赖性而应当增强自己代码调试的能力。
• 可以使用接口代替抽象类，在AirlineMainService（飞机服务类）中还可以将读取和处理功能单出抽出使代码更符合单一职责原则（SRP）

总结与提升

• 思维：在本次总体的迭代训练过程中，本人虽然算法思维提升并没有第一次大但是却提升了面向对象程序设计中更为核心的能力-根据客户需求设计的能力，在一次次迭代的训练中本人也逐渐体会到客户（题目）的需求是会随时发生变化的，这就要求我们在设计时要保证代码的质量才便于以“不变”应“万变”即遵守开闭原则（OCP），在不修改现有代码的前提下，通过扩展来实现新的功能。
• 编码能力：在此次总体迭代过程中本人的编码能力又得到了进一步的提升，比如java中继承与多态，接口的使用，还有IDE调试工具的逐渐掌握，可以自动生成构造方法，getter（），setter（）等等。

建议

• 总体来说本次迭代设计较为成功，可以有效提升学生对java设计原则的理解与运用，但是本人建议在一次总体迭代完成后可以给出出题组所期望的设计思路（类图）或部分源码，即“标准答案”，这样可以让做题者走出“当局者迷”的困境，更有利于提升设计思维。😊

你在本次迭代作业遇到了哪些挑战？欢迎在评论区留下你的建议😀！感谢您的阅读。