第三次java总结

前言：

　　　　最近三次PTA题目所涉及到的知识点主要是封装、继承、多态，题量较少，难度偏低，题目的测试点设置并不好。

设计与分析：

　　PTA作业座机第一次迭代

　　　　

 

 

　　　　如图，设计了许多的类，类之间的关系如下

 

 

　　　　

 

 　　　　其中，用户的付费方式为抽象类ChargeMode，在第一版中它只有一个子类LandlinePhoneCharging，即座机付费方式，每个用户都有一个号码溥，并且号码溥有许多的分类，座机打哪里的座机，手机在哪接听的，发送信息和接受信息等。此版只用到有关座机的。

　　　　第一版的代码结构清晰，但是main函数写的不好，运行顺序不好看，代码也不够好看。

　　　　

　　　　PTA作业座机第二次迭代。

　　　　类的设计如下

　　　　

 

 　　　　增加了许多的类，保留了上次版本的座机功能，并且增加了手机打手机，手机打座机，座机打手机的功能。

　　　　类之间的关系简略的说一下。用户有收费模式的属性，该属性的类型是收费模式类ChargeMode（abstract），他的子类有LandLinePhoneCharging和MobilePhoneCharging。还有收费规则类ChargeRule（abstract）它的子类有许多，每一种收费模式都有许多的收费规则，收费规则就是ChargeRule的子类，例如LandPhonelnCityRule（座机在市内拨打电话的收费规则），在ChargeMode（例如LandLInePhoneCharging）类进行计算收费时会调用该类来计算。

　　　　因为第一版main函数写的不好，所以在第二版重写了一次mian函数，写完之后代码结构清晰，方便修改，可读性极强，有大量的注释。

　　　　main函数代码运行情况如下。

　　　　

 

 　　　　先写了两个函数用于过滤开户操作时的异常情况。

　　　　然后定义了几个正则表达式，只有符合条件的输入才会有效。

　　　　

 

 　　　　首先就是开户操作，只有符合上述几个正则表达式，并且不会被判断用户是否重复过滤掉才会被开出户来。并且一旦离开开户操作（读了一条通话记录）则彻底离开开户操作。

　　　　其次是将通讯记录记录给相应的用户。对应的情况有很多，但都是等效的，这里就只展示手机打手机的。只有符合短信输入的正则表达式，并且不会被判断记录是否重复过滤掉才会被记录。将通讯记录识别并记录到用户的哪个号码溥里的拨打记录，以及识别并记录到用户的哪个号码溥里的接听记录，对通话记录的处理时，则用到了CallRecord类，识别通话记录的拨打号码，接听号码，拨打所在地区，接听所在地区，拨打时长。

　　　　　　

　　　　再其次就是结束部分，如果一旦输入了end，则程序结束，不再接受任何数据。（这里有点小插曲，砸门待会再说）

　　　　

 

 　　　　

　　　　然后就是将用户组里面的用户通过冒泡排序根据号码顺序来排序。

 

 　　　　

　　　　最后就是输出了。

　　　　

　　　　程序到此为止就结束了。

 

 

　　PTA作业座机第三次设计时由增加了短信接收功能

　　类的设计如下

　　　

 

　　　　第三次作业有着代码限制，所以不得不在提交作业时删减了许多的类

踩坑心得：

　　在第二次迭代中输入测试数据c=3.0，d=0.0，思考发现，虽然用户拿到了自己的通话记录，但是calCost函数没有判断用户是作为拨打方还是接听方，直接默认为拨打方了，所以给calCost函数加一个判断。但是这样改的话较为复杂，于是选择在设置balance的时候加个判断。经调试发现并不是这个问题，用户的计费方式是由自身的通话记录判断的，放置的很清楚，接听就是接听，拨打就是拨打。 问题为其中的25行，获取的通话记录表错了，不是userRecords.getAnswerlnProvinceRecords()，应该是userRecords.getCallinglnLandRecords()。

 

　　　　

 

 

　　在第三次迭代中，对信息处理方面，本来是用空格来分割输入内容的，但是信息内容里面也肯会有空格，并且如果信息内容为空，则还会出现没有空格分隔而出现数组越界的情况，因此，直接改为输入内容的第28位以后均是信息的内容。

一切都改好，并且自己测试无误。但是PTA的许多测试点都报错，在怎么想都想不到问题，怎么测也测不出问题的时候，发现了这一行

　　　　MessageRecord messageRecord=new MessageRecord(a.substring(2,13),a.substring(15,26),a.substring(27,a.length()));

中的substring第一个参数可能和我想的不一样，于是将原本的28改为27（将信息截取从第27位开始改为第26位开始），突然就满分了，超级激动，原来卡我这么久的问题在这里。

改进建议：

　　在做大题目时，一定要设计，多花时间去设计，先多想到底怎么搞，程序是如何运行的，题目的要求要如何做才能够达到，不能一上来就写代码。

总结：

　　此次的作业收获还是蛮多的，又是一次新的，从来没有试过的设计方式，以前都是将如何收费写成函数或者直接写在计算收费里面，这次则是将其写成类；以前会将座机收费模式、手机收费模式写在main里面，分区域进行处理计算，而这次则是写成了类并且作为User的属性。有着非常强的拓展性，又一次体会到了开闭原则的美。

　　这次的代码结构自认为非常清晰，并且main函数也很好看，可读性极强，运用了大量的注释。以后也要保持写注释的习惯。

　　

　　再次希望老师能够多出设计类的题目，让我多见识见识还能怎么设计，并且设计能力才是最宝贵的地方