面向对象2022-第四单元作业总结
架构设计：
本单元的任务是实现一个UML解析器，对UML类图，UML时序图，UML状态图进行解析，可以通过输入指令进行查询，并且具有一定的规范性验证能力。
考虑到助教所提供的官方代码已经实现了将输入转化为UmlElement元素，我们所做的工作就是对输入的UMLELEMENT元素进行分类保存，使得查询时方便快捷。下面以作业的部分指令为例。
CLASS_SUBCLASS_COUNT classname //输出直接继承classname的子类
CLASS_OPERATION_COUNT classname //输出classname的操作个数
CLASS_IMPLEMENT_INTERFACE_LIST classname //输出类的全部接口(包括间接实现)
对于CLASS_SUBCLASS_COUNT和CLASS_OPERATION_COUNT，在MyClass类中设置存储sonClass和operation的容器即可。CLASS_IMPLEMENT_INTERFACE_LIST
本次作业的逻辑关系大体上分成三个类别，分别是类图，时序图，状态图。而进一步的细分，或者说类与类之间的关联关系，可以通过_parent来判断，具体例子如下。
{"_parent":"AAAAAAF8pZCdQzQZZWk=","visibility":"package","name":"Class0","_type":"UMLClass","_id":"AAAAAAF8pZCdTTQaucw="}
{"_parent":"AAAAAAF8pZCdTTQaucw=","visibility":"private","name":"Operation0","_type":"UMLOperation","_id":"AAAAAAF8pZCdTTQbmVc="}
其中UMLOperation的_parent指向的是UMLClass，故在类的逻辑建构时UMLOperation很可能作为UMLClass的属性存在，事实上也确实如此。这可以作为本次作业架构的一个基本思路点，通过_parent已经可以完成本次作业类与类之间的逻辑关系了。而剩下的其它细节，则是怎么便于指令查询怎么来。
对于不同类别的UmlElement处理方式也有所不同。有的类会进行灵魂的升华，比如UMLClass进化为举世无双的MyClass；有的类则隐姓埋名，好似UmlParameter蛰居于MyOperation的属性列表之中；有的类秉持着”事了拂衣去，深藏功与名“的侠客信念，诸如UmlGeneralization便只是告诉类和接口他们的父子关系，然后便在父子团圆时悄然离去，甚至还未接受父子道谢和感恩的一杯热茶；还有的类则被人冷眼相看，拒于门外，可否有人听到角落里传来UmlCollaboration，UmlEndPoint的哭泣之音(本次作业可以规避这两个类的使用)。然而，还是有励志的故事在上演，不甘于沉寂的UmlAssociation和UmlAssociationEnd始终怀揣着梦想。终于，在第三阶段新增了相应的有效性判断，从而获得了一席之地，可歌可泣，可歌可泣。
本次作业中还可能面对其它一些有趣的问题。比如说MyImplementation的代码行数超过500行，不妨回忆一下第三单元时我们抛出异常的情景，函数的主要内容都是在另一个类中实现，此处只有一行函数调用代码。通过这种方法可以尽量的将内容分散到其他类中，使MyImplementation尽可能简洁。
@Override
public void checkForUml001() throws UmlRule001Exception {
MyChecker.getComeChecker().checkForUml001(); //在另一个类中再次调用此函数
}
四个单元中架构设计思维及OO方法理解的演进：
回忆起四个单元前，冬雪还未消散，风儿有些喧嚣，面向对象从草地里探出头来，呼唤着自己的昔日好友操作系统。那时的少年轻轻地捡起这两只神兽，踏上了不归之路。
预习阶段：面向对象理所应当。就是把可以叫出名字的东西命个名，宝剑是冒险者的装备，作为冒险者的属性，同时也作为装备的子类。
第一次作业：表达式的化简。或许难以让人想象，为了让电脑可以解析短短一行的表达式，需要用数百行的代码进行分析。类的关系也并不是那么容易看出，表达式下面是相，项的下面是因子，某一类因子还可以被看成表达式，即表达式因子。基本因子也多而杂，有数字，幂次，三角函数，为了化简还需要让项之间尽可能的作出运算。
这也是我人生中第一次意识到，表达式，项，因子，这样的名词居然是有用的，我过去十多年做数学题的过程中都没有意识到这一点，看来面向对象真是神奇的语言。那时的面向对象难点主要是层次架构，好的架构可以让后期拓展相对顺利，坏则可能导致重构。这时我心中的面向对象稍微有些复杂了，有些层次关系并不是像武器装备那么明显。
第二次作业：让电梯跑起来。这一部分的层次架构可能有较大提升空间，不过这是在后期电梯功能扩展时才看出来的，为了避免重构的巨大工作量，我还是选择保持原来的架构。但这并不是说原来的架构就没有亮点，事实上，原来的架构是为了尽可能保持简单。在楼层中装人，会按楼道的按钮，而电梯则会对自己所在楼层中发亮的按钮进行判断，选择适当的策略移动。不过这样做在后期复杂活动的时候会比较麻烦，但仔细去想，人才是决定应该按下哪个按钮的，不是楼道，也不是电梯。然而让人作出最优判断，绝非易事。本次单元还学习了多线程，详情还请看第二单元博客总结。
第三次作业：JML的代码书写。本单元学会了JML代码的阅读，为了性能对关键信息进行维护，本单元中面向对象的感觉也比前两次作业好很多，可能是邮件，人，团体，社交网要形象具体很多。
第四次作业：UML图的解析和规范性检验。同样是面向对象特征明显的一次作业。为了分担工作量，可以将某些类的实现放在别的类中，使得类的复杂度均匀。
那么，架构设计的思维是什么呢？我无法言说，或许是先目测一下可能存在哪些类，然后再完善类的功能。在完善功能的途中会发现要用到其他类，或者说要有其他类的配合，这时便意识到其他类中需要有什么。一步一步慢慢搭建，最后可以实现。但对于复杂的作业会麻烦一些，比如说第一次作业。其类的构建方式是基于处理方法上的，没有解析方式，类与类之间的关系可能也是空谈。
面向对象方法，继承，实现，多态。这些内容在作业中偶尔会有所体现，果然还是怎么自然怎么来。似乎在需要用到的时候，或者说感觉不这么用会感觉不优雅，有些麻烦的时候，就会想到去用这样的技巧。
测试理解与实践的演进
“未经测试检验过的代码，是存在风险的。”
在进入面向对象之前，我对代码的检验方法大致有两种，一种是对拍，另一种是逻辑检验(人眼识别)。不过这并非在一切情况下适用，当正确答案不唯一时，对拍适用性降低。当代码的复杂性达到一定程度时，用肉眼看也不大现实。第一单元中的逻辑表达式的化简结果输出就可能不唯一，直接与好友对拍不太合适，可以考虑使用python的第三方库，然而当引入三角函数并且表达式的复杂性达到一定程度时，在python下就可以观察到Out Of Memory的友情提示。在第一单元时，我选择了相信自己的代码，大大降低了时间成本，不过还是出现了一些bug。
再到第二单元，输出变得更加复杂，肉眼观察输出结果是否正确相当有挑战性，没有办法，我还是选择相信自己的代码，最后出现了线程安全问题。
第三单元终于更新了JML判断方法，并且可以使用Junit工具判断。可惜的是这是最好对拍的一次作业，输出结果具有唯一性，于是就对拍了。第四单元同样有输出结果唯一性，对拍通过。
看样子似乎有些逃课啊，不过我还是干了一些事的。在构造测试数据时尽可能覆盖所有的情况，保证功能性正确。在测试时将上一期的强测数据进行修改，保证数据具有一定的强度。测试时对中测强度进行评估，如果中测强度不够的话多花一些功夫测试。
课程收获
每一次作业对我来说都算是新的挑战吧。第一次作业中有无从下手的迷茫，还好有助教提供了递归下降的代码框架；第二次作业时需要额外了解线程知识，对锁的使用有了基本的了解；第三次作业要学会读懂JML代码，解析时也要具有耐心；第四次作业则强制性地了解了UML图的组成成分，以及对应的规则。
偶尔会学习一些算法，如堆排序的Kruskal算法，求最短路径的Dijkstra算法。偶尔会去了解新的数据容器，HashSet,HashMap,ArrayList,ArrayDeque等都有所使用。偶尔也会去干一些无聊的事，比如测试a++和a=a+1哪种运算速度更快。无形之中也提高了自己处理问题的能力，面对难题时不至于无从下手，无所作为，可以根据指导书的要求一步步往下做。
不过感觉还是差了一些，虽然作业有难度，但需要很认真才能解决的场合还比较少。要是题目可以更强一些，能够更加激发我的斗志就好了。仔细想一想，可能是助教团队留的时间是用来做测试的，而我总是在这一阶段逃课了。。。
改进建议
1、缩短互测的提交冷却时间，这个阶段的等待时间感觉意义不是很大，如果为了减小对大家的压力，可以改成限制提交次数。
2、课程中的理论学习有些欠缺，目前我还不知道工厂模式是什么，可能是老师希望学生自己去了解，可惜我又逃课了。。。
