1.总结本单元两次作业的架构设计
在我动手开始总结我的设计之前，我看了其他同学已经提交在班级群里的博客，不禁汗颜，我是真的偷懒。其他同学大多使用了新建一个类，用以储存每一个UMLelemet元素的具体信息（当然这个类的形式可能是结构、map等等，但核心思路大体一致）。在设计这个类的时候，大多数同学都遇到了困难，耗费了大量的时间精力。
下面我来讲一下，我的第一次作业的架构设计：
最开始，我查看方法描述，考虑如何实现方法的时候，惊喜的发现，UMLelemet数据类型的对象是可以实行操作的！这样一来，问题似乎变得很简单很简单啊。当填充getClassCount方法的时候，我只需要数一数，elments数组中，getElementType等于UML_CLASS的元素的个数，就搞定了啊。剩下的问题，我挨个调用函数，也解决了啊，perfect！good job！我还是太天真了，但当我需要实现getClassAssociatedClassList方法时，我懵了，我们能在elements中调用的方法，似乎并不能实现这个需求啊。
一阵抓耳挠腮之后，我想到了第一单元作业！开始了正则表达式的漫漫征程。一切似乎都在有条不紊的进行着，到这里时，我的思路还和大部分同学一样，正则分割出来的我把它单独存起来，到时候读，自己建立一个数据处理类，来细化数据的分析工作。但是，新的风暴出现了！我在调用UMLelement的toString方法后，发现，会出现\\转化成\ 的情况，这时候，我分割出来的ID值，和调用UMLelement的方法得到的ID值，会出现出入（该死的转义字符）。在经过细致的分析后，我觉得这一方法，实现起来太过麻烦，也太不靠谱。
众里寻他千百度，蓦然回首，那人却在灯火阑珊处。UMLelement的to'Json方法吸引了我，我查阅了解了Json方法，发现，Json方法里按照类一个一个的存储对象，我们的UMLelement给出的方法，其实就是Json中的一部分。任意一个UMLelement类型的对象，我们只要对他的Json进行迭代，就能得到输入的全部信息，不会出现toString里出现的转义字符问题，也不需要自行分割字符串。毕竟，java每次的oo指导书，都会有这样的字眼。不要重复造轮子！
我就使用了iter方法（自建的方法），返回一个String的ArrayList，该方法实现是，迭代当前UMLelement类型对象的每一个元素，并存入ArrayList中，这样每次只需要调用iter方法，就可以访问该对象的所有属性。
此外，对于每个方法的实现，我都采取了设计一个该方法的Help方法，在该方法内调用Help方法，因为这样在处理继承关系（循环找父类）时，会出其的简便。此外也有助于审视方法内的逻辑层次，便于进行逻辑验证，和细碎的形式验证。
接下来，我便要谈一谈第二次作业的架构设计。
第二次作业基本承继第一次作业的设计，除了引入了以下机制：
1.我设计了每个数据type的hashmap，用于存储相应的数据，以便快速查找，因为，在我看来，第一次作业中，查找元素的时间成本由于没有过多的循环，是可以忍受的，而在第二次作业中，这种成本开始逐渐升高。必须采取措施来降低这种时间成本。
2.使用了两个特异化的dfs算法来实现008，009两个检验规则。
3.添加了searchById和eleSearchById，通过id，来快速得到该元素的类名，以及通过id快速定位元素，这也是为了降低日益上升的时间成本。
此处附上我的类图，但由于我是在第二次作业的类中创建第一个类的对象来实现代码，类与类之间的关系显示的不是很直观。
第一次作业类图：
第二次作业类图： 
2.我在四个oo单元中的架构设计与00方法理解的演进
首先，我要说明，由于四个单元的作业若是展示类图，未免篇幅过长，还不够精炼，所以我选择不一一展示类图。
1.第一单元：
第一次作业，此时的oo基础，只有寒假完成的小练习（当时也只是初步学习了java的语法）。所以我在第一单元的第一次作业，设计了一个一main到底的函数，当时还为代码行数刚好没到500，没有触及代码行数限制而沾沾自喜。
第二次作业的时候，由于互测可以查看同屋同学的代码，我在第一次作业的基础上，做了一些改进，例如正则匹配不在是暴力的手撸一个三四行的正则表达式。而是将正则表达式由因子构成项，再由项构成正则表达式。这里我已经有了面向对象的想法思路了。
到了第三次作业，这时候正则表达式已经无法满足需求了，需要循环递归来解决问题，在我的判断输入合法性的代码中，我的面向对象的思维进一步巩固，在我的递归下降过程中，我的函数已经是按照面向对象的思路来完成了，即多项式，拆解成项，项拆解成因子。
总而言之，这个单元的架构设计，还是带着很浓重的c的面向过程的色彩。从第一次作业完完全全的用c的思维写java到第二次作业，在正则表达式构造中体现了面向对象的思想，再到后来整个都面向对象。这个单元中，我最好的情况是程序中部分程序有面向对象的思想，但即使如此，我的主体部分还是面向过程的而不是拆解的面向对象的。
2.第二单元：
第一次作业，本次作业在编码复杂度上并不高，我的四个类加起来行数不到150行。本次作业由于不熟悉wait与notify操作，我使用了暴力轮询的方式，搭建我的框架。事实上，本次作业的完成也是可以采取面向过程式构造的(FCFS的构造单线程电梯也能轻松搞定)，但为了理解与运用面向对象的思维，并为本单元的后两次作业做好铺垫，我使用面向对象的思维，设立了电梯类，控制器类，和指令输入类（控制面板），我的设计与主流设计的区别在于，我的控制器，并不是一个线程类，他只是一个容器类，指令输入类自行往这个容器内放入指令，电梯类，自行读出指令开始运行。整个程序的实现，已经有面向对象的样子了。
第二次作业，电梯数目不变，变化的是对调度算法有了要求，简单的FCFS算法不能再满足此次的要求，此外，对于cpu时间也加以限制，使得暴力轮询的方法不再适用。我的改动一是针对暴力轮询，二是针对电梯类，在电梯类中，加入了判断方向等此次作业需要的方法，三是针对控制器类，这次为了更符合他的功能，我将控制器类重命名为存储类，并添加了此次作业需要的方法。该次作业，对象构造更加完善，对象之间的联系也更加紧密。
第三次作业，有三架电梯，且运行的楼层不一致。架构上，一是改动了电梯类的设置，使得可以使不同电梯可以停靠不同 的楼层，二是将电梯类和存储类一起改动，使得可以使电梯互斥地运送乘客，并完成换乘。本次程序实现，由于前两次代码设计合理，更改时间并不长，很快就完成了程序。而此次的程序，我觉得较好地体现了面向对象的思想。
总之，本单元的程序设计，难度大，但收获也足，本单元的程序设计完成后，我对面向对象的思想有了较为全面的理解。这一单元的几次作业，也都有着不错的面向对象的结构。
第三单元：
第一次作业，本次作业，我选择了维护大量的hashmap来进行快速查找，对于一个path，以他的id和path分别作为key，value进行两次存储，存储的成本不高，查找的成本也较低。只是面向对象的思想并没有过多的体现。
第二次作业，本次作业，设计到较少数量的点却会在较大数量的区域出现，如果直接使用邻接矩阵存储，第一空间不足，第二在进行图的相关操作时，会原地爆炸，螺旋升天。我使用了映射法，即用一个ArrayList存储映射关系，然后直接用映射值代入运算。至于其他设计，与第一次作业大体相同，运用了大量的双休hashmap缩短查找时间。同样的，我认为此次作业中面向对象的思想也没有过多体现，可能在第二次作业继承第一次作业的时候体现了吧。
第三次作业，本次作业与第二次作业一样，可以通过Floyd算法来解决，但需要对Floyd算法进行一些特异性的处理，我设立了一个Floyd模板类，模板类里融合了四种Floyd算法的特异性处理。在存储图的时候，也会根据不同查询的需要来存储多个图。这一次作业中，我的模板类的设计，倒是部分体现了面向对象的思想。
总之，本单元的程序设计，与第二单元相比，难度有所降低，让人喘了口气，但难度也不算过低，也巩固了我的数据结构方面的知识，我自认为我的设计在时间上处理还算成功，这一单元的作业，测试表现都较佳。但是，在面向对象思想上，我觉得本单元作业的考察方式就像是填空题，而不是解答题，我们不是整体的设计，而只是小打小闹，面向对象的思想并没有能展现出他的优势，事实上，在本单元的程序设计中，我也并没有使用面向对象的思想去完成整个设计。
第四单元：
第一次作业，架构设计上，在一个类里完成了所有的实现（现在想想，其实没必要把代码写的这么臃肿，完全可以拆分开来），面向对象的思想也并没有多少的体现。
第二次作业，我就是我，是颜色不一样的hashmap，受到第三单元的启发，我再再再一次使用了大量的双向hashmap来加快查找速度，此外，我还设立了多个help类，用来辅助查找，每个分别负责查询状态机，顺序图，类图等等。这一次的设计，我运用了面向对象的思想，将输入UML图拆分成类图，顺序图等，分别构造处理逻辑解决。
总之，本单元的程序设计，作为最后一个单元，在我看来偏离了面向对象这四个字，换言之，这一单元就是UML元素语法了解单元，而不能看作训练面向对象思想的一个单元。我的绝大部分时间，花在了思考，欸，这个方法怎么实现啊，我要去找那个type的数据，然后去看哪个id啊，UML图能这样画么，这样的数据是满足条件的么这些问题上，而不是花在怎么面向对象的设计代码层次。即使第二次作业，我的面向对象设计比较充足。那也是因为考期过于清闲，有充足的时间精益求精，锦上添花。没错这一单元里，面向对象思想只是锦上添花的思想，绝非雪中送炭的必需思想。
3.四个单元中测试的理解和实践的演进
这一部分，我倒是要改一改前面几部分的习惯，将总结的话放在前面了（莫名其妙的逻辑感）。在四个单元的测试中，我的整体变化是这样的，测试部分越来越偏向于逻辑验证，即坐在电脑前安安静静地一行一行地看代码，用脑子生想bug在哪里啊，bug在哪里，bug就在眼前的代码里。也越来越偏向于对照测试，即与同学的程序一起跑一段测试样例，然后比照结果。大一时，写出个程序，随手造一段强度极低的数据测试就完事的时代已经测试了，这是我在测试上最大的进步。下面，我将逐个单元的具体分析：
第一单元的时候，什么测试经验都没有，就是代入数据，如果对了，哦耶，好棒，错了，就回头改。事实上，这种测试方法只适用于通过中测，强测会挂的程序是很难靠这种程度的测试测出来的。
到了第二单元，我学会了一项重要的测试技巧！边界测试。第二单元的测试我采取的形势验证与重点验证相结合。即重点测试每次作业中易错点或新添加部分，其余部分采取形势验证。这样的测试方法在前两次测试很成功。第三次测试中，我沿用了该方法，只重点检查了换乘部分。却发现由于乘客数量的变化。我的程序，需要改变两个常量的值，否则会出现边界的错误。强侧因为这个直接没进互测，总共就4个字符的改动啊！至今都觉得很气，从此，我必做边界测试。
到了第三单元，我开始部署自动化测试，因为我是一个不push就不会动的人，第三单元的测试已经不是手动输入能够实现的了。此外第三单元，我也开始了大范围的对照实验，制作测试样例，与同学分享，测试程序。最后，第三单元我还学会了Junit等骚套路，虽然在检验过程中，Junit连锦上添花都算不上，粗俗地说，纯属脱裤子放屁，多此一举。
最后的第四单元，这单元，我对测试的理解也大致成型，就是对照测试和逻辑测试。针对第四单元做的特异性测试则是使用starUml构造图，通过jar包导出成数据，然后进行测试。考虑测试手段的话，通过郭同学分享的GUI工具，我的测试自动化程度更上一层楼。
4.我的课程收获
最初，佳处径须携杖去，能消几緉平生屐。
之后，楼观才成人已去，旌旗未卷头先白。叹人间、哀乐转相寻，今犹昔。
当一切尘埃落定，回顾此中点点，平生塞北江南。归来华发苍颜。布被秋宵梦觉，眼前万里江山。
最开始真的是一股少年英气，充满自信开始了课程的学习，奈何终不是那芝兰玉树，戈戟云横，头铁撞的头破血流，感叹oo痛苦，每一个周末，都更想放弃，觉得就这样躺在地上也未尝不可呢。在学期末回顾，这一路的确累，的确不轻松，但眼前也有了那万里江山。
现在，我有了面向对象的思维，这样的思维不仅帮助我有效地处理复杂问题，在我的c++课程的学习中，作用极大，也为以后的工程生涯打下了一定基础，毕竟，要恰饭的嘛。
此外，面向对象的课程对心理也是极大的磨炼，在多项式第三次作业的时候，我的压力值到达了顶峰，周二的ddl，我到周一才找到正确的路径，这次的作业我的总时长接近20个小时，是心理生理的双重煎熬，以前，有过熬夜完成剪辑任务的时刻，可这压力终是比不上面向对象的压力。视频剪不出来，咕咕咕也不是不行，而一次oo作业（尤其是第一单元的第三次作业，后面还有八九次鬼知道是不是比他难得多的作业）即将零分的压力是真的迫人。
最后，面向对象课程也提升了我的测试能力，让我学会了怎么使用git和gitlab方便地进行版本管理，怎么巧妙使用各类插件，怎么提升代码风格，写出规范的代码，这些看起来并不起眼，但我确实受益良多。
5.三个改进建议
1.好玩的任务
不知道潜水的助教有没有关注到这样一个现象，在写电梯的时候，群里大多洋溢着轻松愉快的气氛，不同于写第三单元时群里的沉闷，和写多项式时群里压抑着的怨气。为什么呢？好玩啊，大一专业分流，我身边不少人选择六系就是因为对编程有兴趣，这是一件乐事，学着开心就来到了六系。然而，大一的计组让不少人丢失了这份乐趣，电梯作业时又找回了这份乐趣，那段时间的码代码真的是蛮欢乐的，希望给以后的学弟学妹多安排一些像电梯这样的任务。
2.在互测屋内增加点赞功能
很多同学都反馈，希望能看到优秀同学的代码，但是。。。助教的反馈其实蛮迟的。这完全可以理解，毕竟助教也有自己繁重的学业任务，要从学院的数百份代码中挑选出优秀的代码分享给同学们是很费时间的一件事。但是，把这件事分配给同学们完成助教们就会轻松很多。就我而言，当我侥幸进入A屋时，同屋的大佬写的代码经常让我惊为天人，漂亮的架构，漂亮的嵌套，忍不住看了又看，只是可惜不能分享给全部同学。可以在互测屋内增加点赞功能，只要点赞数不可见，应该也不影响什么公平性，而助教只需要对点赞数高的代码进行人工审查，就可以选出优秀的代码分享给同学。
3.精益求精
例如指导书，可以写的更详细一点，课程安排也可以更合理一点（理论课紧接着实验课总觉得太赶），这样的小细节，如果再进步一些，下一届同学的oo体验会更好。
2019-06-23 21:31:16