写在前面
初次接触面向对象设计与构造这门课时，我对课程组的教学方法和要求是感到极为不解的，特别是看到长达数页的指导书和不近人情的互评制度时。笔者当时想：我们所学这门课程的目的，不是为了学习面向对象编程的思想吗？但是，课上讲的内容仓促不精，写作业时候也是要花费大量的时间去阅读指导书，甚至这样也不能搞清楚设计的具体要求。当我们写完程序时，又要花费大量的时间去测试，课程组是不是过分强调测试，而忽略了面向对象本身呢？
但是后来，随着不断的深入了解，我才渐渐懂得了课程组的这样要求的目的。
“我们写的是软件而不是程序”，这是吴际老师在第一节课的时候告诉我们的，现在想想这句话说的真的非常有道理。我们所写的东西应该对于任何情况下的输入都可以响应，也就是说，程序在任何时候都不能崩溃。我们在写代码的时候应该要考虑许多的东西，输入规格，输出规格，容错处理等等，而不仅仅是程序的功能本身。
另外，在开发工程项目的时候，你的客户并不会明确的说清楚他所要的规范，所以我们要有自行思考规范，理解客户的需求。所以，自行了解程序的需求也是一个很重要的能力。
最后便是测试的能力。现代工程的开发，测试往往会比写代码本身要花费更多的时间。对于一个复杂的程序，没有bug几乎是不可能的。我们测试自己的程序，阅读测试别人的程序，这些都是对我们软件测试能力的一种锻炼。
不得不说，面向对象设计与构造这门课程教会我们的不仅是面向对象的编程思想，更多的是一个programmer应有的素养。
正文开始
好了，不在唠叨了。接下来，我将分析一下三次作业，以及自己的心得体会。
首先，我想先来说一下我的测试策略：
1. 根据分类树，对于每个节点去构造简单有针对性的测试样例来测试我拿到的代码。
2. 如果出现问题，就去阅读被测者的代码，找到bug所在。
3. 当测完正常功能后，就进行压力测试，随机生成大规模输入，来检查程序的响应结果。
第一次作业
第一作业是多项式加减运算。这次作业的算法非常简单，只要你将多项式成功的读入之后，运算就非常简单了。所以，我认为第一次作业的难度就在于对输入的处理上。
作业分析
程序类图
这次的作业我是用了三个类，其中Poly用来保存多项式的特征，并且定义多项式所包含的方法。ComputePoly用来从输入中读取多项式，并且进行计算得到结果。CheckInput类用来检查输入是否符合规格。
度量分析：
从上面可以看出，我的Gnpoly方法复杂度较高。这是因为，我在用正则表达式匹配多项式时，没有去整体匹配，而是运用多个正则表达式去分别匹配单项式和多项式。这样，就会在读取输入的时候较为复杂，拖慢程序的效率。
难点分析
1. 我们在做c语言的题目时，往往题目都会要求输入规范。也就是说，测试数据并不会出现违反输入规格的情况。但是，OO作业却要求我们对于任何情况的输出程序都要做出响应，也就是容错处理机制。
2. 那么我们用什么去处理输入呢？课程组推荐我们使用正则表达式。那么如何正确的运用正则表达式就成为了一个难点。
3. 程序的压力测试？对于大规模数据，程序是否崩贵。我们要借助try-catch来处理异常。如何正确使用java的异常处理机制，也是我们所要做到的。
出现的问题
这次的作业，我的公测没有错误，但是我忽略了对于程序异常情况的处理，所以在互测得时候被发现了bug。而我所评测的同学也同样出现了这个问题。原因在于：我使用了数组，虽然我将数组的规模开的很大，比如我用数组a[1000]去储存多项式中每个单项式的指数。因为题目要求单项式最多只有50项，所以我天真地以为肯定不会发生溢出。但是，对于不合法的输入，比如输入一个单项式数目超过1000的多项式，正确的相应应该是提示输入不合法。但是我的程序却会因为数组越界而崩溃。
通过和舍友的交流，我还发现了第一次作业还可能出现的其它问题：
1. 我们在使用Integer.parseInt()方法来讲字符串转化成数字的时候，可能会因为字符串所代表的数字大于int类型的最大值，而出现异常。
2. 使用正则表达式直接匹配输入时，当输入的规模过大时会发生栈溢出错误。
我的心得体会
1. 我们在完成程序时，不仅仅要考虑完善正常功能，对于容错处理一定要做好。也就是，任何情况下，你的程序都不能发成异常！
2. 正则表达式在进行字符串匹配时，会发会巨大的作用。一个好的正则表达式可以让程序变得更加简洁。
3. 由于在正式写作业之前，已经写好了c语言程序。所以，我更加深刻地了解了面向对象与面向过程程序的区别，体会到对象世界的无穷魅力。
第二次作业
相比于第一次作业只有两个类，这次作业课程组直接要求我们去写至少五个类。这样，不同的类各司其职，完成一个傻瓜电梯的运行，程序具有很高的封装性。这次的作业在功能的要求上是很简单的，由于不具有捎带功能，程序只需要逐条读取输入，进行处理，输出结果就好。
作业分析
程序类图
这次作业我用了六个类。其中主要的功能在request，elevator，queue和scheduler上。mainclass类从控制台读取输入，构造request对象，然后加入queue对象的ArrayList中。之后，scheduler开始工作，一次从ArrayList中读取请求，构造elevator对象进行处理。另外，mainclass还进行输入规格检查。
度量分析
从上面可以看出，程序的复杂度主要在与judgesame方法上，这是因为我为了不出错误，而将所有的请求都进行比较，而且比较的方法十分复杂，所以才有了较高的复杂度。
难点分析
这次作业的难度，笔者个人认为是调度器的构造和同质请求的判断。在有了第一次作业的教训和经验后，相信大家都已经很好的掌握了输入规格检验和容错处理方法，所以这部分应该不会存在问题。但是，如何去模拟电梯的运动过程，得到电梯的运动状态就成为了难点。另外，如何去判断同质请求也是一个难点，如果判断条件没有写好，往往会遗漏一些同质请求。
存在的问题
1. 据笔者了解，大概有两种去设计的方法：第一种就是模拟时间的方法，在程序中模拟时间的流失，来得到电梯的运动状态。这种方法可以更加直观地模拟出电梯的运行，但是这种方法最大的缺陷就是对于较大的时间，比如t=2^32-1时，程序可能会花费较长时间才能给出相应。第二种是直接计算得到，虽然简单效率高，但是却很难直观地显示电梯的运行状态。
2. 关于同质请求的判断遗漏。这个问题是笔者在最初写的时候出现的，部分同学也存在。笔者在最开始的时候，当读到请求队列中的一个请求时，仅仅和前一条指令进行比较判断，这样就会漏掉许多情况。
心得体会
这次作业总的来说，比第一次难度要低。我想主要是因为我们对于正则表达式更加熟悉，对于容错处理也更加得心应手。但是，这次作业让我学会了调度的问题。如何去构造一个好的调度方法，让程序变得直观形象而又不出错是一个难点。
第三次作业
第三次作业是在第二次作业的基础上增加捎带功能，让电梯变得更加智能。重要通过类的继承和方法的重写和重载来完成。虽然在功能上没有太大的变化，但是要改变或重新写的代码却有很多。
作业分析
程序类图
这次的作业，我在继承上次作业的基础上，新增加了ALS_scheduler类，用于完成捎带功能。与上次作业的主要不同就是电梯的运行方法，同质请求的判断以及调度器的构造。
度量分析
从上面可以看出，由于对不同条件下的捎带请求都要进行判断，所以checkbring方法具有很高的复杂度。而程序的主要性能也却取决于调度器中是如何判断一条请求是否应该进行捎带。
难点分析
1. 显而易见，这次作业的难度就在于调度上。满足什么样条件的请求可以被捎带？如果捎带多条指令，如何更好地计算出请求的执行顺序？
2. 关于同质请求的判断问题。当电梯的调度策略改变后，排在后面的请求有可能被先执行。那么满足什么条件的指令才是同质请求呢？
3. 捎带和同质嵌套的情况？
存在的问题
这次的作业笔者在完成的过程中充满了坎坷，由于一开始没有想清楚电梯的捎带策略，我把捎带的条件写错。甚至只考虑到了上行的情况却没有考虑电梯下行的情况。另外就是在同质请求的判断上面，笔者最开始直接继承上次的方法，直接将一条请求和它前面的所有请求进行对比。但是，某些排列在后面的请求先执行的时候，就没有进行判断，这就导致自己的程序出了很大的问题。最后，由于对指导书的意思理解不正确，我错误的认为只有当一条请求的发出时间位于主请求的发出时间之后时才可以捎带。
在互评过程中发现的问题：
笔者在这次的互评中发现，许多同学的问题都出在调度方面，而且都是因为没有正确理解指导书上的意思，没有仔细地去分析捎带的条件而导致遗漏。
心得体会
这次的作业让我理解了继承的思想。如何很好的继承前面的代码？如何重写父类的方法？如何写出一个正确简洁的调度方法？这些都是我在这次作业中学会的。
感悟
经过四次课程的学习和三次作业的磨练，我对于面向对象编程思想有了初步的了解，明白了它和面向过程式程序的区别。面向对象的核心特征：封装、抽象、继承和多态，就是用代码来模拟现实世界某些事物的运行方式。面向对象式代码具有较高的动态和具象特征，程序在工作时就是在不断地创建对象和回收对象。
不得不说，三次作业让我初步具备创建规模较小的面向对象式程序的能力。但是，我所写出的程序仍然还有着很重的面向过程味道。比如，某个类可能很长，有的类却几乎没有内容，核心功能全部集中在一个方法中等等。这些问题，都需要我不断地多写程序来解决。在日后的学习过程中，我相信自己会更加熟练。