面向对象程序设计题目集七至九技术总结

前言：题目集七至题目集就题量对于前几次题目集，题量小，总共四题，而且难度对于我来说不大，基本都是一遍过。题目集八和九都是关于atm机的例子，代码量大，重点考察的是对于类间关系设计的理解。接下来简要分析一下这几次题目集。

题目集七：题目集七有两道题，但这两道题很相似，所以说只要写完了其中一道题，第二道题改一改就能用了。题目集七的第一道题是图形卡片排序游戏，要求对输入的各种卡片数据进行排序。这里只有四种卡片，分别是圆形，矩形，三角形和梯形，所以设计思路肯定是要设计四个类，然后在业务类中实例化对象然后再来进行排序，出于代码复用性的考虑，可以设计一个抽象类shape，然后前面提到的那个四个类可以作为shape类的子类，虽然这样设计对这道题来说，这个抽象类的有无都是不会影响程序的运行的，抽象类的使用只是会影响到后续代码的复用，所以可以设计一个抽象类在这个实验中。由于给定类图中有一个comparable的接口，所以这里也设计了一个comparable的接口，该接口是为了比较各图形面积，以便更好地排序的，下面给出类图。

上面所示的类图即为题目集七的类图，因为题目集七的两题代码中唯一不同的部分就是DealCardList类中的方法，因为这两题的要求大同小异，只是单纯的输出结果的形式不同，总体来说题目很简单，下面贴出sourcemonitor给出的分析，由于两题给出的复杂度报表一样，所以这里只分析一张报表。

 

 可以看到DealCardList类中最大复杂度达到了18，而其他类中的复杂度都低于10，接下来具体看一下该类中的方法的圈复杂度。

 

罪魁祸首是showResult方法，该方法的圈复杂度为18，是主要贡献者，回顾两题中的代码，发现由于要进行格式化输出，在保证输出格式的同时使用了大量的if和for循环，增加了大量的圈复杂度

 

 有诸多上图所示的代码在该方法中，由于大量的格式束缚和水平有限，无法对该代码进行优化。

题目集八：题目集八为ATM机类结构设计，题目集八代码量大，当时写到半夜两点钟，可谓是亲手写过的最长的代码，主要是让我们自己进行类间关系的设计，该题的任务书都很长，但是已经给了很明确的提示下面先给出主要的类图再来进行讲解。

 

 这是我画的类图，该图主要所表达的是各种类间关系，由图可以看出，card，account，user，bank，cup形成了一种链式关系，即都是一对多：银联有多个bank，一个bank可以有多个user，一个user可以有多个account，一个account可以有多个card。这种链式关系在代码里的体现都为ArrayList，使用一个list来存储。但这样处理就造成了一个查询问题，即通过卡号找账户，找银行等等，当时我采用的是遍历查找，我需要哪个数据就写个方法来查找，这样显然是造成了性能的浪费，后来老师在课上讲解时提到了可以使用双向链表，这样的话就只需要写一个方法就可以完成所有信息的查询。由于本题需要大量的进行初始化数据，所以单独设计了一个类initdata来进行初始化数据，然后在该类中写了大量的方法来实现程序功能，所以可以预想该代码质量应该很差，下面给出sourcemonitor给出的圈复杂度报表。

 

 结果显示圈复杂度为12，而initdate类中的圈复杂度仅为3分析代码可知，因为主要是在Main类中实例化了initdate的对象，以及在Main类中使用了大量initdate的方法，所以导致圈复杂度过大。圈复杂度要想减小可以试着往双向链表方向改进，毕竟查询会使用大量的性能。

 

具体分析代码之后发现对字符串的处理有大量的if嵌套，这些应该可以整合成一个判断数据非法的方法，来降低圈复杂度，当时一心只想要过测试点而忽略了代码的质量，以至于写出了这种辣鸡代码。

题目集九：题目集九相比之下简单得多，因为老师给出了源码，所以当时我也没有急着写这题，因为已经可以预想到要改动的部分 。下面直接上类图

 

 上图为简要给出的类图由于只是对老师的代码进行简单的改动，所以保留原来的类结构的基础上增加了一个抽象账户类，然后该抽象类有两个两个子类，这两个子类一个是信用账户一个是借记账户，使用这种设计模式，可以实现多态，我设计信用账户和借记账户的思路就是，借记账户的可透支额度为零，这是这两个的唯一区别。所以设计的时候的属性设置的值不一样，设计完这两个抽象类之后，紧接着就是修改Withdraw类中的代码，将之前的非法判断修改即可，接下来贴上圈复杂度报表。

 

 最大圈复杂度11，超过了10比前几次好的很，基本已经达到了要求。

踩坑心得：由于这几次作业的难度都不大，而且大部分都是一遍过，少部分因为考虑不周全，多跑了几次，都是不大问题，这次也没踩到几个坑，所以就没啦。