为什么写OO博客这么难

Part-0.3 对于博客

　　万事开头难，虽然说博客只是作业的一小Part，但是确实是自己第一次写一些关于编程方面思考的文章，之前从来都是写一个感性的小文章，思考思考人生啥的。而且我相信写好博客是很重要的一个环节，毕竟态度最重要嘛哈哈。俗话说七分看三分写，好的作品总是要一遍一遍推敲，所以这周二一整天的时间我都想用来做这件事情，不能说自己以后能坚持多久，但总归是迈出了第一步，就认真点吧。

Part-0.7 对于OO

　　说是面向运气编程，不如说是面向指导书编程。

　　毕竟分配作业是个技术活，像我这么非的人只能靠自己努力了。

　　顺利搞定OO的秘诀是心态，还有读懂指导书。

　　写作业最费的还是眼睛。

　　其实，相比于前三周的编程，最难的事情还是在要放清明假期的时候，稳住心态认真把博客写完吧。就像狼人杀一样，最有意思的事情还就是复盘了，因为这是你拥有信息最多的时候，这个时候如果都分析不好的话，那信息少的话更不可能Carry全场了不是嘛？所以趁着自己记忆不太模糊，好好的回顾一下还是蛮有意思的对吧。

Part-1 后验之明

　　三次作业从结果来看，看起来写的还可以？没被别人挑几个错，倒是也没挑别人几个。第一次1:1，作业被人挑出了一个输出的ERROR，挑了别人一个Crash；第二次0:0；第三次3:0；好像看起来写的都没啥问题对吧？

　　但是毕竟人们去做反思的时候都是已经知道了结果的时候，所以这个时候的思考很难做到客观，或者说很难还原当时的场景与心态。就好像考试得了100分之后，就忘记了考场上有多么犹豫不决似的。

　　每个人的程序在真正跑出结果之前，很少有人能够百分百保证自己的代码完全没有问题，所以真正的DeadLine之前，重复的检查自己的程序就变成了人之常情，但是这样真的好嘛？人不是所有时候都能保持一颗平常心的，越是到最后，发现自己有错，就越慌乱，可能越改越错。其实可能只是某个大括号没有对齐？或者是样例输入错了？对自己的算法自信一点，才是我们真正应该训练的不是嘛。

　　当然，这就需要我们在真正动手之前全盘的规划了，所以说，其实OO的核心就是仔细阅读指导书，尽可能和同学们多讨论讨论边界情况，然后理理思路看看哪里有难点，不要害怕自己的独到方法被别人学了去，让更多的人帮你检验你的算法，更能帮助你理清思路呀。

　　所以最好还是不要唯结果论，因为全部正确也不代表没有错误，更不能代表代码简洁思路清晰，毕竟怎么走过来的只有自己知道，所以适当的反思是必须的，而且还要装作自己不知道结果的反思，和高中英语似的，有了标答谁都能站起来“合理”分析一通，没有标答能肯定自己的程序没有BUG的才是高手呢对吧。

Part-2 还原场景

　　现在就先回忆一下当时拿到指导书到提交截止前的经历吧。

一、第一次面向过程的JAVA

　　最开始拿到指导书的时候，感觉这道题好简单呀，原来数据结构不是写过类似的题嘛？感觉根本不用费啥劲，果然第一次作业就是让大家练练手。正巧那一周忙忙冯如杯，于是周二晚上才开始真正动手，也预示着这会是三次作业以来唯一一次熬夜。第一次作业就写到三点？？？什么鬼？？？

　　可想而知第一次作业写的并不是很用心，脑子里唯一想的就是能不出BUG就行，根本不在意是不是写的精细。由于时间紧迫，也来不及学习正则，好在之前了解点JAVA，写一个面向过程还算顺利。所以第一次作业的就是一个完完全全的面向过程，不会正则表达式，因为既要写C，又要写JAVA，所以就选择状态机好了。在纸上画好所有的状态，就开始动手写C了，顺利写完之后，开始跑几个代码，才发现由于没有好好阅读指导书，连要支持系数指数的正负号都没考虑到，心想，反正是C程序，不用考虑结果的完全正确，改都懒的改了，一会儿一口气把JAVA写完就可以睡觉啦！

　　于是确实很快就把程序写完了，跑起来也还可以，该实现的都实现了，不过就是只有一个类，丝毫没有体现出对象的优越性，但毕竟心想能正确跑出结果就足够啦。第二天抽时间把Readme写完，就自信的交了上去。所以说，虽然没有什么问题，但是写的好不好只有自己心里知道。

　　那一周的OO实验上，第一次不得不用正则表达式，也是被迫速成，才体会到了正则的极度便捷。

　　第一次作业，最能让人收获点东西，因为这奠定了后面的OO之旅呀。

　　1.早点准备，不一定要动手，但是一定要想好怎么写。就好像写C的时候，磕磕绊绊，好多情况没想到；但是写JAVA的时候非常顺手，就是因为清晰了所有的指导书要求，而且程序的各个部分了然于心。

　　2.感觉作业都不会太难，不像算法，应该不存在一点头绪都没有的情况，但是麻烦是必然的，所以如何防止缝缝补补才是关键。

　　3.关于面向对象，这一次匆忙，没有关于技术方面的认知，之后才体会出一些Debug方法。

二、一个看起来不错的傻瓜电梯

　　曾为年少无知不谙深浅，但少年总会成长的。根据第一次的所得开始第二次作业，提前准备。早早地把指导书读了几遍，大概有了些想法，之后又间断的想了多次，找到了一个认知范围内感觉最方便的方法，周日晚上完成了输入部分，周一11小时的课没时间，周二上午一小会搞定了控制部分就完成了，而且没有什么错误，一下子就能跑起来。

　　第一次尝到了提前构思的甜头，也是因为这一次作业比较简单，所以各个类之间的关系相对来说很明确，但是分工并不太均匀，结构过于扁平化，出现一对多的情况。这一次没有继承和接口，所以类图看起来单一一些。

Begin类：属性为电梯、楼层、控制器、请求列表，方法为信息输入，main函数用于程序的执行，负责创建Controller\Elevator\Floor\RequestList四个类。
Controller类：属性为现在请求、现在时间、之前时间等，方法为执行下一个请求、控制电梯并输出结果、忽略同质请求，负责协同Elevator和RequestList。
Elevator类：属性为现在所在楼层，方法为生成请求、移动、显示当前楼层，生成Request加入RequestList中。
Floor类：方法为生成请求，生成Request加入RequestList中。
Request类：属性为标志、目的地、方向和请求时间，方法为返回标志、目的地、方向、时间，主要负责存放数据，被他人生成。
RequestList类：属性为存放请求的动态数组，方法为添加请求、返回请求、移除请求和是否为空，被Elevator和Floor进行增操作，被Controller进行减操作。
Element类：用于存放常量。

三、半智能的意思不就是半智障嘛

　　从这一次作业开始慢慢体会到了OO 的本质。

　　怎么能有这么奇奇怪怪的要求？？？这一次从周日开始看指导书，光是读懂就花了我一天的时间，主要是下午觉得有很多诡异又矛盾的地方，直到晚上新版指导书发布所有地方才清晰。周一一天的课也没动手，相当于构思了两天才开始写。想了两种方法，第一种就是和上一次作业相似，从List中找到下一个执行的请求，然后执行，如此往复；第二种是新建另一个List，找到一条主指令，然后把他的捎带都找出来放到新的List中，然后不停的排序，往复。当时一直在两种方法中纠结，因为每当选定一种方法之后，进一步思考，总能找到一个更不好解决的问题。但也幸亏如此，才让我把两种方法都通顺的思考了一遍，最终还是选择了和上一次有一定顺承关系的前一种方法。

　　于是周二下午开始动手，一直写了大半天，终于搞定了。可喜的是这样长时间的构思下来，几乎所有地方都考虑到了，而且由于一开始就有一定的全局准备，即使是巨型方法也有很清晰的层次感，虽然更好的方式应该是把它拆成多个小方法，但是修改起来也有了很好的便捷性，知道自己需要改哪里，只需要改哪里。

　　最难的地方，应该是学会如何合理地继承。由于写第二次作业的时候没有做继承打算，所以对于方法的继承还是很困难的一件事情，因为控制器的集成度太高了，几乎所有方法都是为特定情境而编写的，除了数据结构和同质检测，其他的都要重载，甚至连用都不再用。这就需要弱化方法的功能，尽量减轻单一方法的代码量，避免巨型方法的出现。

Begin类：属性为电梯、楼层、控制器、请求列表，方法为信息输入，main函数用于程序的执行，负责创建Controller\Elevator\Floor\RequestList四个类。
Controller类：属性为现在请求、现在时间、之前时间等，方法基本全被Override。
Elevator类：属性为现在所在楼层，方法为生成请求、移动、显示当前楼层，生成Request加入RequestList中。
Floor类：方法为生成请求，生成Request加入RequestList中。
Request类：属性为标志、目的地、方向和请求时间，方法为返回标志、目的地、方向、时间，主要负责存放数据，被他人生成。
RequestList类：属性为存放请求的动态数组，方法为添加请求、返回请求、移除请求和是否为空，被Elevator和Floor进行增操作，被Controller进行减操作。
Scheduler类：继承Controller类，使用其属性，重载方法。属性为主请求，捎带请求，计数器等，方法为选下一个捎带请求、下一个主请求、判断同质请求、执行请求、改变电梯方向、删除请求等，负责协同Elevator和RequestList。
Elevator_method接口：规定了Elevator类应该具有的方法。
Element类：用于存放常量。