结构分析
经过对老师本次作业指导ppt的一番研究和拜读，发现自己对面向过程式程序有着根深蒂固的眷恋。
不论是作业一，二还是三，都出现了不同程度的方法代码量不均衡的问题。尤其是作业三，ALS调度类的核心方法行数超过二百行。
作业一中parsePoly方法出现超长问题：
事实上，在分析自己代码度量的过程中，发现自己在前几次作业中对类的用法和对面向对象程序的看法似乎有着一些误区。我有时为了实现一个功能(函数)，去创建一个特殊的类，这个类刚开始甚至没有特有的属性，而在其他类中调用时创建的对象只是专门为了这个函数去创建的。在之后实现方法的过程中，再为这个类添加各种各样的属性，甚至有些属性单纯的是几个方法要一起使用的全局变量。比如在第一次作业中，我的ComputePoly类中有两个方法，第一个方法是把字符串中的多项式提取出来并存在数组里，第二个方法是把数组里的字符串加在一起。在实现的过程中，我几乎丝毫没有体验到面向对象编程的思想和优势，很多时候，我只是把类看成了struct和function的集合，但并没有把对象之间的关系和所谓封装理解清晰。
而第一次作业付出时间最多的，就是学习正则表达式，以及Java中相应的类的用法，比如Matcher类和Pattern类。在逻辑实现上并没有遇到困难。
第二次作业有所改善，因为作业中出现了比较具象的电梯和楼层，我在编程的过程中试图去加入如 猫会叫，叫声是喵喵喵、还会挠人，爪痕是balabala...... 这样的属性和方法，但在实现过程中我确立了一条指令一条指令地处理的思想，因为这电梯有些Fool，就跟遛狗一样，叫它去哪就去那，因此设计中构思的上一层，下一层，或者按按钮等操作，都没能用上，只是试图引入了一些特殊的属性用来判断同质请求。判断同质是这次作业的核心也是较难的问题，因为处理输入输出的部分在第一次作业中有了经验，因此稍显得心应手。
第三次作业在第二次大体结构不变的情况下重写了Schedule方法，在我个人的实现中简直就跟新建了一个类没啥区别，因为我之前的scheduler类里就没什么特有的属性......这也因此导致了我的ALS_Schedule无论是代码长度还是度量中都显示出无以伦比的巨大。
总的来说，第一阶段作业中从结构来看我对面向对象程序的理解并不是十分深刻，希望在未来的作业中能有所改进。
BUG分析
从我编程的经验和经历来看，bug有以下几种：语言问题，逻辑问题，实现问题。
语言问题很好说，写着写着旁边都是大红叉就可以边写边de，编译都过不了。编译过了之后也会因为某些原因直接Crash。因此善用搜索引擎，还是很容易debug的。这种问题往往出现在初次接触某种语言，不清楚语言的语法和语言的一些机制。我在某个同学的博客中就看到这样的例子：ArrayList加入某个对象时不是加入对象的副本而是加入对象的指针，导致同学一个Temp从头Add到尾都是一个Request。我在过程中也遇到了如他一般的问题，可以说是自己挖坑自己踩了。
逻辑问题，在面对指导书要求时的设计思路，设计思路如果有误，在设计完成后想要更改往往需要花费巨大的时间，在我第三次作业的Coding过程中，发现设计思路出现了一些问题，导致某个情况下的捎带识别需要直接重构逻辑才能解决，抓耳挠腮心态血崩。经历一番思索才发现可以取巧，幸好不用改大体逻辑，要不然怕是得推倒重来了。
实现问题，在实现中或许会遇到很多的手抖，或者写着写着忘了，或者是其他原因。这些问题的体现有时是一个大于小于号，有时是一大段代码的逻辑与期望偏移，这也是我认为在测试中最难覆盖的，因为你的问题不一定出现在什么情况下，或许它真的很特殊，分别测试功能都没问题，一旦在某种情况下，这个功能就会出现问题。而这些问题往往只能通过一行一行地调试进行解决，非常消耗精力和时间。
在我的三次作业中，bug的出现往往是因为疏忽和手抖导致的，有时很确信对一个情况的处理完全正确也会出现问题。
我在debug的过程中发现，如果我能把代码相似的逻辑整合，尽量减少多次判断和重复的操作，不仅降低了代码量，还可以有效进行模块化，从而更容易地debug，因此在未来的程序实现中，我会逐渐调整编码的方式与策略，尽量避免这样的bug出现。
心得体会
oo这节课确实很奇怪，有时候大家会说，oo肯定不会比计组再难了。但在我的学习过程中发现，每周学习计组的时候就比较有条理，有一个很好的网站可以提供所有的资源和教学内容，这让我学起来很轻松，也更愿意去打开cscore。记得当时学计组的时候，一打开Chrome就会点上面的cscore网站。或许是听了过多的传闻，对计组比较恐惧，所以学习就很认真，也花了更多的时间。而oo，我分配给它的学习时间有些别扭，因为在学习过程中，我没有一本合适的工具书做参考，上手基本全靠百度。事实上，我想实现一个功能，我需要的方法名字和类名字我是不知道的，也很难检索它到底存不存在这样一种方法。我要不就去看jdk里所有的类，一个一个查，要不就去百度上试图描述问题来碰运气。因此我认为学习过程中一本深入浅出的工具书是很有用的，起码看目录能知道我都有哪些工具在编程中使用，否则会一直使用旧有的c语言思路。
谈及对面向对象的认识，我可以大致勾勒出一个好的面向对象程序应该是什么样的，但是自己实现起来却有着大量的不一样。比如电梯，如果我按指令进行操作，让电梯上一层这个操作完全没有意义，而直接去目标楼层反而是比较简便。因此我只能删掉脑海中的电梯up方法，去直接创建一个setPosition方法。大量的set和get让我觉得自己就是在用一个带函数的类。不能访问的变量就是这个类内部自己用的一些操作所需变量，能访问的属性就相当于c语言中的结构。这让我对对象的理解有所恍惚。另外，我曾经想让电梯去哪，再让电梯直接输出(5,UP,5)这样的字符串，但是时间这个属性在我的设计中只有Scheduler类里拥有，如果交给电梯打印还要给电梯传参，这让我不禁产生了这样的操作意义何在的疑问。但是把打印写在scheduler里又显得scheduler的职务过于复杂。有时我就是在这样或那样设计的纠结中慢慢壮大了自己的某一个类，最后形成的庞然大物削减起来却又格外困难。不过我相信这样的情况会有所改善，我在慢慢的明确各类的职务和功能，也在慢慢地把它向指导书的要求靠拢。理想中的电梯机械音“6楼到了”，就是我想把打印放在电梯类里的想法来源，这样会增加设计的复杂性，但换来了职务的划分明确。或许编程就是要费一些力气，去让未来的自己或者别人能更简单的看懂代码。因为代码总归是要维护的，前期的设计成本如果降低，写程序不过脑子一直敲，那么后期的维护成本也就格外得高。磨刀不误砍柴工，为了提高程序的健壮性和易读性，我还有很长的路要走。
