OO第四次博客作业

OO第四次博客作业

零、写在前面

终于到最后了QAQ。这第四单元，处在一个比较尴尬的时间段（考期），所以每次作业的时间都比较长；但这也并不影响思维难度和码量（轻轻松松破千）。总的说来，第四单元就像助教说的那样可以近似认为是一个小软件了，针对于解析UML的软件，只是缺少了一些封装。可能这也是码量大的一个原因？

回顾四个单元，第一个单元是懵懂期，还不太懂面向对象的思维方式，代码结构也较为混乱；第二个单元就好多了，多线程电梯通过一个仔细思考过后的架构设计使得三次作业基本上是代码复用而不用大规模重构；第三个单元JML也是如此，到这时面向对象思维方式就已经比较成熟了，虽然出了一些状况，但那是数据结构的算法问题，不是咱的面向对象问题；第四个单元UML图经过架构思考后基本上代码实现也很自然，主要还是算法问题稍费工夫。

一、架构设计

第一次作业

话不多说，先上类图。

由于指令纷繁复杂，所以刚开始如何处理这些众多的指令成了一个思考许久的难题。最后是构建了一个类似“数据库”的data类，通过这个实例化这个类可以进行指令的新增、查询和更新，很大程度上降低了代码的耦合度和复杂度。这个类的建立也是极大地提高了编码的速度，事实上，编码的时间倒不如思考架构的时间长。

那么架构设计也就非常清晰了。Data负责指令的存储和更新这些底层逻辑，MyUmlInteraction里实例化data，通过数据库间接访问指令，然后只需要处理自己的应用逻辑就可以了。最后出了一点意外状况，还是应用逻辑有一点没有考虑周全，强测就凉凉。可惜。

第二次作业

也是先上类图。

由于第一次数据库的构建，使得这次代码架构方面就很轻松了，但是也可以很清楚的看到多了好几个类，这些类是干什么的？其实很简单，因为第一次作业只有一个类图，所以也用不着分离出去；但这第二次作业多了时序图和状态图，所以要把这三者分离开来（细分的话还有三个R规则，也可以分离出一个规则检查类，但是并没有这么做）。这三个类共享一个实例化的data对象，类似于单例模式的思想。

本次最难得几个方法是R规则QAQ。这三个R规则着实花了一番功夫，层层递归（也可能是那两个类的六个方法太简单了，没有对比就没有伤害233）

二、从架构看对OO理解的演进

第一单元对于面向对象还是比较陌生，编码思维基本上还是面向过程思维，按部就班地就把三次作业整完了。正则表达式的运用是第一单元的主题，第一次、第二次作业虽然没有用大正则去匹配整个表达式，但是把表达式项用正则表达式来描述，第一次还是绰绰有余但第二次的正则表达式就非常冗长了。但还是比较幸运地通过了中测和强测。第三次就惨了，因为尝试使用相同的编码思想，发现根本无法构造出符合题意的表达式项，于是白白浪费了一天时间。之后选择了用+号来分隔出基本因子和嵌套因子，思想还是没有太大问题的，但是数据处理出现了纰漏，导致了强测出现问题。架构设计也比较混乱，如果现在让我回去看第三次作业，那我肯定是不愿意看的；因为代码结构乱的让自己都有点反感。

第二单元就好多了。多线程电梯，往年的传奇单元，似乎在我这里并没有很困难？！主要还是归功于第一次作业痛定思痛，做了充分的分析后构建了比较合理的生产者-消费者模型，通过taker和waiter两个类来实现电梯的进出和waiter向taker的转换，第三次作业由于不能直达又出现了taker向waiter的第二次转换。这个单元最初肯定是比第一单元要痛苦的，因为多线程编程是之前从未有过的经历。但是入了门之后也就轻松了，因为第二单元的合理架构处理起来实在让人舒爽，大片代码复用是第一单元想都没有想过的事情。至于dispatcher调度器和elevator电梯的逻辑分离，这个我觉得不用多讲了，思考架构的时候就应该想到如此。总之，通过waiter和taker两个类的建立，这才真正意义上代表了自己对于面向对象编程思想的理解和应用，我觉得这是第二单元给我们最大的收获。

第三单元JML，希望我们能规范自己的代码风格，使其标准化。我觉得这个单元没什么好讲的，就是理解JML规则，然后应用到代码中去。我倒比较认可这个单元是一个数据结构还债的单元，大片算法优化问题，仿佛让人恍如隔世。

第四单元UML，让我们编写代码实现对UML图的解析。这个在前文已经讲过了，引入一个Data数据库，使得数据处理与业务逻辑分离开，较好的实现了解耦，所以编写起来还算比较顺利。难点还是理解UML的规则，比如之前根本没有听说过Java接口多继承的事项，UML还是给我们开了一个新天地的。其他的嘛，难度还是算法问题吧。主要还是Data数据库的建立，这个架构使得后面处理业务逻辑变得异常轻松。

对于OO的理解，从第一单元一脸懵逼到后面的运用自如，自己也说不清是通过思考架构来增进了对于面向对象编程思想的认知还是通过面向对象编程思想的逐步深入来帮助建立了更加合理的架构。反正这两者紧密联系，密不可分。如今再让我编码的话，肯定不会拿到就动笔的，架构分析某种意义上要比落实编码重要得多。

三、测试的理解和实践的演变

第一单元的测试比较朴素，基本上是通过手敲边界数据来测试，但这样的问题也很显而易见：容易出现纰漏。事实上，第三次作业就出现了比较严重的纰漏，导致了大规模的强测爆炸。不能让人满意。

第二单元由于多线程编程的原因，测试bug难以复现，所以事实上这个单元也测试的很少。但是幸运的是，从结果上看，这个单元反而是最安全的一个单元。

三四单元基本上就是和同学们互拍，通过这种方式来找bug。但由于数据是随机的，所以很多bug也无法找出，只能依靠大规模的测试来降低bug出现率。也没有更好的办法了。

四、课程收获

一、最大的收获就是收获了面向对象编程思想（OO课都结束了还掌握不了面向对象编程思想的话那也太咸鱼了吧233）。由于之前没有接触过面向对象编程，而且数据量规模偏小，所以在刚接触面向对象时会产生抵触，这是自然的。但是当后期代码规模膨胀之后，之前的老一套就很难用了，分类的思想的重要性也愈发的体现出来。就拿电梯来说，仍让我面向过程编程，我无法想象会写成什么样子。

二、掌握了规范的代码风格。说的就是你，checkstyle。这东西第一次用的时候，感觉是如此多余，要强行按着他的要求来改自己的变量名和方法名，让人很不痛快。但是后来也发现了它的好处，就是可以让代码变得规范，比如不允许一个方法超过60行、一个文件超过500行的设定，看似多余，实则让代码耦合度大大降低，所以说，规则限制了自由，但无法无天的自由是危险的。checkstyle虽然限制了自由，但它也避免了危险，强行要求解耦会使之后的修改变得更加便利。

三、体验当了一把社会上的程序员。意思就是体验了一把代码分工的感觉，因为二三四单元都是有官方包的存在的，这种官方包的存在使得自己在实现业务逻辑的时候变得十分便利（鬼知道第一单元的正确性检查难度媲美多项式求导给人的感觉）。

四、架构思考与设计。这门课之后，基本上不会再拿到题就开始动笔写了，而是要好好思考一下如何构建结构，这将会为编码带来速度的飞跃。

五、建议

一、实验课。实验课是上午学新内容下午便现学现用，困难有些大。但是到了后面的实验似乎感觉上难度和最初不是一档了，可能是官方已经注意到了这个问题？但是还是感觉实验课存在的意义并不明显，因为在短时间内完成现学的任务，一定程度上要求了难度不能偏高，而作业的难度是足够大的，相比而言，实验课的存在便有些尴尬。

二、对于作业难度和重心的调整。事实上，第一单元的正确性处理的复杂度甚至可以媲美多项式求导，咱也不清楚这是否是课程组有意为之；第二单元还好，但一二次作业几乎只是修改了一项内容：捎带，新增的内容是否有些单一（因为从助教那里得知这第二单元第二次作业放假的大有人在）；第三单元到后面几乎是在搞算法问题而不是OO问题，是否存在重心的偏移；第四单元就很好了，虽然理解难度很大，但是有老师的暖心贴和助教的详细解释，降低了难度。

三、互测问题。我知道互测是这一届的新的尝试，所以有改进的空间也是正常的。主要的问题是，互测刚开始大家还会去满怀热情的去翻看他人的代码，一点点找问题，而到后面大家往往就懒得去一点点地翻看了；这当然也有OS的因素，因为要花费时间来学习OS，那当然是没有OO作业的星期三、四了（恰好这就是互测的时间）。所以时间上的冲突也是一个因素吧。到后面大家都习惯了用对拍程序大规模生成样例来盲狙，这应该与课程组的希望相悖。