面向对象第四单元及期末总结

本单元架构设计

 一个学期的oo课程便就这么结束了，按照惯例，少不得感慨一番，谈些什么学有所成，谈些什么继往开来。不过，既然标题里的第四单元在前，还是得谈谈这个单元的。
 在整体上，基本采用的方式为在最开始构造MyImplementation这个类时，便对输入的元素的信息进行分类，形成许多业务类，如MyClass,MyCollaboration等。之后进行相关的查询时，在MyImplementation中先寻找到相关的元素（如MyClass），之后直接调用Myclass中的方法进行查询。
 于此同时对于一些在不同类中均有使用的方法或者极其独立的算法，则采取了为其新建立一个类的做法。如下图所示。

 分别表示检查给的数据是否合法，上文提到的元素分发，利用name或者id获得指定的object和判断一些情况的类。使用这种方法能够降低代码的重复度，使可阅读性更高。
 除此之外，在某些具体的查询的时候维护了数据结构，大致思路和上个单元相同，故不再赘述。

架构设计思维及OO方法理解的演进

 说在关于设计架构以及面向对象思想上的成长，自然是有的。大而化之的谈，自然也就是什么“掌握了面向对象的思想”，“体会了设计架构在工程中的应用”云云。至于再往下一点的理论，可能凭空说出便有些困难了。不过，最直观的改变，可能就在阅读之前代码的时候了吧？现在再去回顾pre时写的代码，倒是觉得应该重构。举个最简单的例子，诸多瓶子和装备都有使用这个功能，当初的自己虽然实现了继承，但对每一个使用几乎都是重新写了一遍。现在来看，单是一个“子类是父类”思想，便能猜测出他们都应该有相同的一部分功能；其次是创建类型和声明类型，虽说在pre的知道书中有所提及，但真正的理解倒是在第二单元左右自己使用、摸索的过程中，包括自己的理解错误之中所得到的，类似的例子还有很多，在这里就不一一列举了。思维影响，多是潜移默化的吧。

总结自己在四个单元中测试理解与实践的演进

 说到测试，在第一次作业没有通过的时候，和助教谈过一次话，话题不知怎么的就说到了测试，他说，他们当时做了很多自动化测试，但是做完之后，倒是觉得空虚，毕竟把任务都交给了机器，自己没怎么思考。现在想想，倒也确实是这样，自己和一些同学在三四单元都采取的是自动生成数据加对拍测试，这样做最直接麻烦就是出现了问题，要从一堆数据里面找原因，背后体现的就是，存在逻辑错误或者说是没考虑到情况，不去思考，而是通过数据来检测。到也不是说孰优孰劣，测试就不重要什么的。只不过真实的工程的时候，很难说测试数据能够完全覆盖所有的情况，就如同那个经典的去酒吧点东西的笑话，没人知道顾客会不会点一份“炒饭”，程序的逻辑以及鲁棒性还是不可忽略的一部分。

课程收获

 怎么说呢，在谈完上面的两个主题后，在谈谈课程收获，到确实有点不知道应言何物，既然如此，便谈一些既不是面向对象，也不是测试与实践方面的吧——关于自己的工程安排。这个学期基本上oo的做法是周一晚上浏览指导书，写下自己的思考和实现的方式以及难点，之后周四的时候实现大致框架，周五晚上再完成全部的任务，周六则根据情况检查或者对拍。除了第一单元有点手忙脚乱意外，之后的几个单元在总体上安排的到还是可以。这一套流程下来，倒是增添了几分对任务评估的自信（自信到周五晚上10点才开始动手QWQ）。或许这个也是这门课程锻炼的一项能力吧，或许应该称之为，项目管理？

改进建议

 最主要的想法还是说关于面向对象这门课程可能过于注重实践而稍微的忽视了一点理论。确实是有理论课的支撑，但总感觉理论课的内容都过于宏观了，在具体的指导上，对于我来说就稍微有一些难以和实验相联系。这个学期还选择了另一门面向对象课程———“c++与c#”，这门课程倒是对oo有所反哺，体会到了很多面向对象思想，很多可以直接指导实践的理论。诸如上面提到过的“子类是父类”，以及“never pass by value”这种能够直接指导代码的思想。可能在oo课程中，确实有这些内容的暗示，但我确实也是在c++课上才“恍然大悟”。
 其次是关于第四单元互测的。之前看助教在群里提过，这个单元没有互测的主要原因是能够保证公测的数据都是从真实的uml图中得到，而如果需要互测，则需要进行元素检查。我的对此的想法是，可以是提交的数据直接为.mdj文件，之后利用官方包的解析获取元素。同时每个单元的任务也改成相适应的指令加元素检查的形式，同时选取好检查的规则，限定可能的情况，从而达到能够进行互测的目的，是第四单元的“oo味道”更足。
 最后在谈一谈指导书吧，第四单元的指导书，一言蔽之，没问题，但是理解起来可能需要带点猜测，特别是在刚刚接触这个单元的时候，在阅读接口文档之前，不清楚自己到底要做些什么，即使是阅读之后具体的操作步骤中也带着一点猜测的性质。可以考虑对指导书加入以及接口文档加入一个小小的目录是具体的功能更加明确。