OO第一阶段总结

结构分析

　　通过对老师本次做业指导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楼到了”，就是我想把打印放在电梯类里的想法来源，这样会增长设计的复杂性，但换来了职务的划分明确。或许编程就是要费一些力气，去让将来的本身或者别人能更简单的看懂代码。由于代码总归是要维护的，前期的设计成本若是下降，写程序不过脑子一直敲，那么后期的维护成本也就格外得高。磨刀不误砍柴工，为了提升程序的健壮性和易读性，我还有很长的路要走。