第一次博客作业
OO博客作业
一． 第一次作业
1、程序主体
第一次作业实现一个可以计算多个多项式的加减的模拟计算器。在读入数据时，我学习了JAVA中正则表达式的使用来匹配输入的字符串格式，以及分割匹配不同部分以供后面的计算使用。由于当时对JAVA的编程并不了解，所以并没有使用面向对象的思想方法来写，而是在处理数据和计算的过程中只使用一个类来完成，所以最后程序是面向过程的。这也为后面的debug造成了不小的困难和不便。
类的大致说明：
Poly类实现了对于字符串的读取，正则表达式的匹配，运算符号和多项式的获取，多项式的计算以及最后的按指数升序输出功能。
具体的程序控制流程图：
2、程序结构度量
Poly类：共286行，无属性，一个方法。
程序类图：
优点：不需要考虑类与类之间的调用和关系，方便思考。
缺点：不是面向对象的程序，没有类的属性、方法调用，对ERROR问题处理得很麻烦，代码量多，不简洁。
3、分析自己程序的bug
第一次OO作业是我第一次接触JAVA语言，也是我第一次运用它，因为不熟悉语言的方法与应用，所以写出来的代码可读性差，而且因为ERROR问题处理的不好，导致程序有些时候会因为出现了减号，无法正确识别后面的加号，导致运算结果出错。另一方面，对于指导书的阅读不够仔细，会在输出中输出系数为0的项。
4、自己发现别人bug采取的措施
第一次作业我分配到的测试任务是一份公测数据全部通过的作业，所以我需要应用极端情况测试他的作业，自行构造自行测试集进行本地测试，如果出现错误，就分别检测到底是什么原因导致他的错误。
二、第二次作业、
1、程序主体
第二次作业是模拟不会顺路捎带的傻瓜电梯，通过时间优先的策略，对有效的请求进行排序，再实现。作业的输入我依旧使用了正则表达式来进行匹配，对于同质请求，我用的是递归比较的方法，在已完成的队列中一个个比较，如果是同质请求就忽略，否则执行。
各类大致说明：
Elevator类：用于计算电梯执行一次有效且非同质的请求需要花费的实践，电梯所在楼层的变化，并返回数值给Controller类。
Floor类： 用于判断当前输入的字符串格式是否正确并传递给新建的Floor对象。
Queue类：用于实现请求队列的结构并位Request类的使用提供方法。
Request类：用于实现控制台的输入提取，以及队列的加入，并返回有效方法供Controller使用。
Controller主类：有main方法，作为主类，控制请求的队列的删除，并向Elevator类提供指令，最后实时输出电梯运行状态。
2.程序结构度量
Elevator类：共67行，有8个属性，10个方法。
Floor类：共112行，有7个属性，10个方法。
Queue类：共20行，有1个属性，4个方法。
Request类：共75行，有2个属性，4个方法。
ExpHandler类：没有属性和方法。
Controller主类：共75行，没有属性，1个方法。
程序类图：
优点：按照作业要求将程序分成了5个类，每个类完成自己的工作并与其他类传递信息，另一方面属性与方法的构造使得后续的计算变得简单。对ERROR问题的设计更加整体化、结构化。
缺点：有的类完成的工作多，有的类完成的工作少，甚至并没有很大的意义。对于类的设计仍有很大的局限性。
3、分析自己程序的bug
这次作业没有什么太大的问题，但是实现方法有重复赘述的地方，导致下一次作业的改动变得困难。没有对100条指令进行分析，有可能会造成爆栈crash。
5、自己发现别人bug的策略
这次的互测作业是一份有个人信息的无效作业，虽然不再需要寻找别人的代码bug，但是可以提醒自己不要犯同样的错误。
三、第三次作业
1、程序主体
第三次作业是模拟会顺路捎带的傻瓜电梯，通过时间优先的策略，对有效的请求进行排序，再实现。作业的输入我依旧使用了正则表达式来进行匹配，对于同质请求，我用的是递归比较的方法，在已完成的队列中一个个比较，如果是同质请求就忽略，否则执行，对于正在执行的主请求，在请求队列中通过判断条件将可以捎带的请求加入到可捎带队列中，再执行可捎带队列和主请求。
各类大致说明：
Elevator类：用于计算电梯执行一次有效且非同质的请求需要花费的实践，电梯所在楼层的变化，并返回数值给Controller类。
Floor类： 用于判断当前输入的字符串格式是否正确并传递给新建的Floor对象。
Queue类：用于实现请求队列的结构并位Request类的使用提供方法。
Request类：用于实现控制台的输入提取，以及队列的加入，并返回有效方法供Controller使用。
Controller主类：有main方法，作为主类，控制请求的队列的删除，并向Elevator类提供指令，最后实时输出电梯运行状态。
ALS类：构造了一个有当前可捎带队列和主请求的结构。
Scheduler类：继承Elevator类，但新生成了一个捎带函数用来完成电梯在捎带过程的工作。
Interface类：抽象接口，归纳Elevator的所有方法。
2、程序结构度量
Elevator类：共70行，有5个属性，8个方法。
Floor类：共118行，有7个属性，10个方法。
Queue类：共23行，有1个属性，5个方法。
Request类：共120行，有2个属性，5个方法。
ExpHandler类：没有属性和方法。
Controller主类：共287行，没有属性，3个方法。
ALS类：共31行，有2个属性，7个方法。
Scheduler类：共75行，有5个属性，10个方法。
Interface类：共13行，没有属性，8个方法。
程序类图：
优点：按照作业要求将程序分成了8个类，每个类完成自己的工作并与其他类传递信息，另一方面属性与方法的构造使得后续的计算变得简单。对ERROR问题的设计更加整体化、结构化。引入接口和继承使程序更加工程化。
缺点：有的类完成的工作多，有的类完成的工作少，甚至并没有很大的意义。对于类的设计仍有很大的局限性。
3、分析自己程序的bug
这次作业是在第二次作业的基础上利用继承和接口机制完成的，因为第二次作业并没有留下需要解决的bug，所以这次作业只需要完成捎带方法即可。在写程序的过程中，因为自己考虑得不够全面，所以在进行测试时还是存在一些没有覆盖到的情况造成的bug，但在改进后，所交的程序通过全部公测，也没有被找到 bug。
4、自己发现别人bug的策略
这一次拿到的互测作业很多关于格式的公测测试点没有通过，也告诫着我在以后的编写代码的过程中要注意细节问题，关于寻找bug的策略，这一次我通过利用之前构造的逐点测试集进行测试，这样可以节约测试bug的时间，也可以在发现bug时选择最准确的分支树报错
四、心得体会
前几次作业，是我不断认识学习JAVA的过程，通过在作业中运用正则表达式，发现它对于匹配格式的方便性，对于一些JAVA基本类型的学习，比如说arraylist的使用可以很大程度上方便功能的实现。在学习java的过程中对于类和对象有了更深的体悟，同时，第三次作业中对于接口和继承机制的使用也使我了解到java继承、多态、抽象的特点。在互测机制的影响下，我对一个程序的要求反复观察、再与别人交流，加深了要求，让我们在现实的多如牛毛的要求下共同进步，大抵就是互测机制的愿景了吧。
