OO第一次博客做业

尝试使用Eclipse中的AmaterasUML工具，可是始终安装不成功，因此类图是使用的商业版的IDEA自带的UML Support工具制做。
同理，尝试在Eclipse Oxygen和Eclipse Java Neon安装Metrics报错，使用IDEA的MetricsReloaded分析度量

关于MetricsReloaded：
ev(G)：表示程序的结构化程度，值越大表示代码段越难维护；
iv(G)：方法之间的紧密程度,二者呈正态相关；
v(G)：判断程序的复杂程度，值越大表示方法越复杂，在必定程度上能够看做方法越难维护；

1.第一次做业（多项式加减）

类图：

度量：

第一次做业能够看出，Poly类的getArray方法iv(G)和v(G)两项的值都很大，说明对于方法的抽象不够，这个方法应该能够抽象成几个小部分，这种写法说明程序比较偏于面向过程。

2. 第二次做业（简单电梯）

类图：

度量：

第二次做业的Elevator.calculate()方法的ev(G)、iv(G)和v(G)值都很大，我本身写的时候也意识到了将大部分的调图处理放置在一个方法里面是不合适的，在调试的时候很是麻烦，对于数据的封装性也很差，可是由于第二次做业比较简单，因此也没有进行方法的调整。

3. 第三次做业（ALS电梯）

类图：

度量：


因为前两次没有注意将不一样性质的处理方法抽象出来，因此此次将主要的调度仍是写在一个方法里面，后期debug的时候出现了很大的问题，也致使了第三次做业的失败。

分析本身的Bug

前两次做业比较简单，因此在程序逻辑设计上并无太大问题，公测和互测检查出来的Bug都是在细节问题的处理上：好比忘记处理了楼层数字的前零，还有对于同一个错误，输出了两个错误提示信息。
可是第三次做业暴露出了不少问题，致使公测中关于捎带的测试点基本都挂了。
对比分析了本身的代码和公测拿到的大佬的代码以后，意识到了实质问题出在对于面向对象思想的理解和对于程序总体的架构上，好比对于无效输入和同质输入，个人处理都是在具体的代码段使用两个System.out和continue语句，可是由于程序中须要不少这样的判断，因此致使代码出现了大量的冗余，而后在指导书更新的时候，须要在每一处修改细节，浪费了大量的精力。而更好的处理方法以下：

class ERROR{
    public static void errorOut(String str, int type) {
        if(type == 0) {
            System.out.println("INVALID[" + str + "]") ;                
        }
        else if(type == 1) {
            str = str.replaceAll("\\(","");
            str = str.replaceAll("\\)","");
            System.out.println("#SAME[" + str + "]") ;
        }
    }
}

构造一个错误处理类，使用static修饰类中方法，使用时不须要new一个新对象，须要输出错误时只须要一行ERROR.errorOut(str,type)便可。
其次就是变量命名的问题，好比我最开始使用TIME表示系统时间，而time表示当前请求时间，这种命名方式就很naive，阅读性不好，无疑是给本身debug的时候增长难度，而好比使用curTime表示系统时间，reqTime表示请求时间就很清晰。

分析别人的Bug

找出别人的Bug的方法，无非就是阅读别人的源码和使用本身构造的样例。
前几回做业中和室友协做，使用在线文档的方式根据分支树构造了比较完成的测试样例集合，因此在测试别人代码的时候比较有用。
第一次做业比较简单，找到两个Bug；
第二次做业对面公测挂了10个，同质挂了一堆；
第三次做业，拿到一个大佬的代码，虽然没有找到bug，不过阅读源码也很有收获。

心得体会

1. 代码在必定程度上是越精简越好，冗余的代码维护起来十分费劲；
2. 对于面向对象思想的理解：将功能相同的模块提炼成类以及方法；
3. 总结来讲就是写的代码太少，对于面向对象的练习不够。