OOP第三阶段总结Blog

  前言：题集7-9主要在于类的继承、多态性使用方法以及接口的应用，以及ATM仿真系统。

 

（1）题目集7：

（7-1）图形卡片排序游戏：为随机发放一些卡片给学生，卡片分为 四种形状：圆形（Circle）、矩形（Rectangle）、三角形（Triangle）及梯形（Trapezoid），并给出各种 卡片的相应参数，要求学生能够迅速求出各卡片的面积大小然后将卡片按照其面积值从大到小进行排 序，同时求出所有卡片的面积之和。本程序仅用于为学生所玩的游戏提供正确答案的功能，即根据学生得到的卡片种类与数量，给出 排序前和排序后的卡片顺序，同时给出所有卡片的面积之和。

（7-2）图形卡片分组游戏 ：其规则为随机发放一些卡片给学生， 卡片仍然分为四种形状：圆形（Circle）、矩形（Rectangle）、三角形（Triangle）及梯形（Trapezoid）， 并给出各种卡片的相应参数，要求学生首先根据卡片类型将所有卡片进行分组（一个类型分为一组， 所以最多四组），然后能够对每组内的卡片根据面积值从大到小进行排序，同时求出该组内所有卡片 的面积之和，最后求出每组卡片面积之和中的最大值。

 

设计与分析

7-1

 

  

 

7-2 

 

 

 

     7-1，通过设计出一个抽象Shape类，进而对Shape进行拓展，其中在主类进行对象合法性的检验以及对应图形数量的添加。在不同的主体类中有着大致相同的方法：求面积，合法性校验，Set，Get方法，在DealCardList业务类中进行对对应具体图形类属性的添加，进而将实体类与业务类联系起来。实体类都继承于Shape类中。而在代码中设计了求面积的接口类，实现了求面积的多态。

 

  就7-2而言，添加的功能有：对初始求出的面积数据进行分组；对分组后的数据在组内进行排序；得到全部图形中的最大面积。实体类设计与7-1无差别。

 

改进建议

1.改进点更多在类中方法的设计以及功能算法设计上。在7-1中，对于排序上采用的依旧是插入排序法，而也尝试过去使用sort排序，这样的代码更加的简洁有效。后发现使用后会无法得到结果，再完成了7-2后发现，我排序的对象的card里的i，而不是i对应的对象。所以若能将全部的排序规则改进为sort排序，则可以将代码更为简洁。

2.求组面积和的功能上，不需要如上述写的在分组之后，再重复遍历去求和，再进行组与组之间的比较。可以在分组的时候，便同时进行面积的加合，待全部的图形面积完成了对应的分组，也同时完成了面积和的运算。

 

分析总结

    两次作业带来的感觉就是面向对象设计在添加功能上的技巧性与规范性十分重要。若为了添加功能反复的使用if语句以及for语句，则是面向过程编程的设计思路，虽然可以同样实现功能但是若数据庞大，则难以进行功能的添加与数据的处理。所以从迭代递进的设计来看，需要从初始属性，功能设计的开始就要遵循“开-闭”原则以及单一职责原则，为了类可以进行扩充，为了类单一定向功能的实现，使得后续维护或者功能添加有方向可找，不会盲目在业务类中进行方法的堆叠。在两次卡片游戏中，收获了对ArrayList存储对象并调用对象实现的方法的熟悉使用，不仅可以符合面向对象设计的原则，也可以在添加类功能上，完全进行适应，通过列表对象调用方法，可以高效可观的完成对应的任务。最多的是对类似于：排序法，基本语法，基本算法，对象创建，add方法等基础方法综合使用，成功的迭代是在原本代码的基础上做对应功能的添加，而不需要大面积更改，对此我仍需要学习如何真正践行“开-闭”原则。

 

 

（2）题目集8：

（7-1）ATM机类结构设计（一）：尝试使用面向对象技术对银行用户在 ATM 机上进行相关操作的模拟系统设 计，上述的相关概念均要设计为实体类，业务（控制）类请自行根据实际需要进 行扩充和完善。 注意：为降低难度，本次作业限定银行卡均为借记卡（不能透支），且不允 许跨行办理相关业务（例如在中国建设银行的 ATM 机上对其他银行的账户进行操 作）。实现功能 ⚫ 基础数据的初始化； ⚫ 用户存款、取款及查询余额功能。

（3）题目集9：

（7-1）ATM机类结构设计（二）：尝试使用面向对象技术对银行用户在 ATM 机上进行相关操作的模拟系统设 计，上述的相关概念均要设计为实体类，业务（控制）类请自行根据实际需要进 行扩充和完善。 注意：本次作业中银行卡包含借记卡和信用卡两类，且允许跨行办理相关业 务（例如在中国建设银行的 ATM 机上使用中国工商银行的银行卡进行业务操作）。1）系统的测试用例均采用如上数据，且所有卡号密码默认为“88888888”， 初始余额均为 10000 元。 2）手续费默认均从银行卡所对应的账户中自动扣除。 3）跨行业务手续费收取比例由 ATM 机隶属银行决定，例如，用户手持中国 工商银行的银行卡在中国建设银行的 ATM 上进行取款操作，则手续费收取比例为 中国建设银行的相应比例，按初始化数据中的规定为取款金额的 2%。 4）跨行查询余额不收取手续费。 5）透支取款手续费由中国银联统一规定为 5%，最大透支金额均为 50000 元。

 

 

ATM机仿真题目的设计思路分析总结

 

设计与分析

7-1

 

 

 

 

 

7-2

 

 

 

 

   题目集8的7-1，主要是设计一个ATM，然后具有一定的存取款，分帐号，可多人多卡存取，显示余额，以及一些错误提式例如卡号不存在，不能跨行存取等。

 

  题目集9的7-1，主要在继承、多态、抽象上面，还有关于”开-闭“原则的运用，大体内容是与题集8的7-1相似，但是更为复杂了，出了储蓄卡还有了借贷卡，并且可以实现跨行存取，但收取手续费。

 

 采坑心得

 

 

   该部分为判断取款金额是否大于余额的判断，以及对判断结果对应的数据处理。其中容易掉入的陷阱是，若金额已经达到了透支，则不适用money = amount的数据处理。一开始设计单纯的采用单一的数据处理，后测试点部分无法通过，进行了透支测试后发现了问题。

 

 

  该部分代码进行对账户的类型判断，进而对对应账户进行不同的账户余额检验，例如借记账户仅用考虑10000的上限，而信用账户拥有贷记的功能，有50000的透支上限，两类不同的余额检验需要分开进行判断。

 

改进建议

 1.在判断是否是贷记账户类还是借记账户类上，这一步如可以不用进行类的判断，设计一个统一的接口进行同名方法处理，则更可体现出多态性。也延续了代码的可拓展性以及可维护性。

 2.业务类太多，可以设计两个业务类甚至多个业务类，例如数据校验判断和数据处理类，让代码更简明一些。

 

分析总结

 

两个ATM题目，从难到更难（对我来说），设立账户，校验输入数据，然后实现存取款和查询，再到分信用卡和储蓄卡，还可以跨行，再收取手续费，变得更复杂，但无语也与现实生活中的atm功能更加贴近，考察的依旧是：继承，多态，抽象类，类间关系设计以及对于“开-闭”原则，单一职责原则的掌握。以及迭代到的不仅是相同背景内容的功能添加，更有考虑到类间关系，去充分利用实体类的属性绑定以及方法调用。业务类中集成方法去实现最终输出的效果。本次ATM机迭代编程，本身逻辑层面简单，注重的是严谨的设计思想与正确的面向对象编程思维。

 

大总结

   本次阶段的三次作业，更多的是对所学类设计的应用，主要是对两种原则的掌握：“开-闭”原则，单一职责原则。以及对于封装性，继承，多态，复用等的进一步学习，理清需求，增加功能，不断完善，学习的加深，题目也在变得更多元化，更贴近现实生活，初提笔时总觉得十分困难，但靠着资料的查询与借鉴，对java也逐渐有了一些理解，尽管还是不咋地叭，还是继续努力，多花费一些课余时间！