从面向过程编程向面向对象编程的过渡基本上是每个程序猿的必经之路，在我印象里面，面向对象是一个和常规思维相冲突的方法，一切事物皆对象，通过面向对象的方式，将现实世界的事物抽象成对象，现实世界中的关系抽象成类、继承，帮助人们实现对现实世界的抽象与数字建模。通过面向对象的方法，更利于用人理解的方式对复杂系统进行分析、设计与编程。同时，面向对象能有效提高编程的效率，通过封装技术，消息机制可以像搭积木的一样快速开发出一个全新的系统。
而在这次面向电梯编程作业中，我已经被oo这门课的坑震惊到了：
从最开始的多项式计算开始我已经感觉到了一丝挂科的气息//滑稽，oo将作业与现实工程紧密结合，程序的鲁棒性是我们在数据结构和计组里面从未考虑过的，反正程序crash是不可能crash的，就算大佬爆栈也是不可能crash的。在多项式计算程序设计的时候，程序的容错处理却是整个设计里面最让人头疼的问题，合法格式否？关键字完整否？数组溢出否？int溢出否？互测阶段可能出现的各种刁难都是需要考虑在内的。当然，虽然这样的课程设计非常坑，都是和工作后的程序设计也是很像，程序的输入流充满了不确定性，任何一个意料之外的输入流都可能带来意料之外的结果。
第二次作业正式直面电梯，电梯相较于多项式而言更加适合面向对象方法的使用，楼层类、电梯类、请求处理队列等等都是很适合将其作为对象来处理的。不过电梯问题的复杂度也比多项式要高很多。
第二次作业还有第三次作业的类图大概如上所示，Input类处理输入，AskDisposeOverride是对第二次作业AskDispose的继承，而AskQueue包含main方法，储存请求队列。Bug分析：几个类的工程量差异较大，AskQueue只需要实例化对象和开数组存数据即可，而AskDisposeOverride类代码量较大，我对电梯问题的分析和指导书完全一样，以主请求捎带子请求的方式来遍历请求队列，由于电梯内请求和楼层请求的不同，需要分类讨论的代码部分很多，极易产生少写漏写等问题。另外这次我终于明白输出格式是一件非常非常非常重要的事情，在输出格式上翻车实在是太遗憾了。而在互测环节分析其他同学的bug的时候，抽到的只有大佬和萌新的代码，有点代码写得无可挑剔找不到bug，有点代码连指导书的基本要求也达不到。在互测的过程中发现大家还是比较侧重于“溢出bug”的检测，可以先查看互测代码中各个数组的大小再花样尝试各种数组溢出情况。
在这三次的作业中还是发现自己的代码一般低级bug较多，比如输出格式啥的=_=，在以后的作业里面还是要be patient。