BUAA_OO_2020_Unit4 Summary

一人成木，二人成林，三人成森。

​

——忘了从哪听的也没找到出处假装是我自己说的

感谢一路帮助的小伙伴，感谢ljh、pgh、cwx、xhc还有各位帮忙跑数据的大佬、帮忙看dfs的bug的cjb、虽然无比嫌弃我但还是帮忙java入门的lyj等等等等。万分感谢。

第四单元三次作业架构设计

三次架构基本相似，最多是在第一次的基础上修修补补。所以就仅放上第十三次作业的UML图。

第一次

把原包里所需要的各个类重新定义为一个新的类（没有全部重新定义因为我摸了，其实或许全部重写在各种意义上可能都会更好看一点），原来的类作为新类的一个属性存在。例如从UmlClass——>MyUmlClass。这仿佛是种叫适配器的模式。鉴于第一次的查询是集中在对类的查询，所以我的查询都放在了类内部，类中囊括了它的各个元素，事实上，在某种意义上，官方包干的事情相当于把图拆解，而我又把图根据各元素与关联重新构造。所以MyInteraction仅仅提供了一个查询接口。

其次为了性能，冗余存储现得很重要。

第二次

第二次作业比着第一次作业多了状态图与顺序图的查询，但各种查询基本分离（按照逻辑他们是有对应关系的，但作业并没有要求到），所以把各个图分开分别作为类，MyGeneralInteraction依旧只提供接口，再把各个解析、查询下发到MyClassInteraction等图中。本次作业稍微困难的一点在于后继结点的统计，虽然没有时间的限制（10s==无）稍不留神便会出错。

第三次

第三次作业集中在对于有效性的检查，但这查询似乎也是各个图分开的（谢助教体恤？，基本上难点集中在2、3、4的检查，其他都是简单的改点东西或者不改就可以解决的。2、3、4倒也不是特别令人头秃，毕竟助教给予的10s善良足够养育贫瘠的代码土壤。但谁让人总是要跟自己过不去呢，还非要想着把检查跟后面类的查询合并，实现检查后查询可以直接输出。这理论上当然是可以实现的，但是实现（对于我）道路艰难。在完成getImplementInterfaceList与R004（？好像是）的合并后，我放弃了没事找事，放弃了tarjan实现的风险，dfs真香。毕竟正确性是第一位的。而关于R00x，也都是分散到了各个图中，顶层只提供接口。

四个单元架构设计

第一单元

第一单元有点像是面向过程到面向对象的过渡，第一次作业简单的面向过程便可实现只不过后面要重构罢了（。此时自己完全没有架构的理解，也完全不给之后的自己留后路，怎么写着方便怎么来怎么容易拿分怎么来（当然后面被打改了）。除了对面向对象的逐步熟悉，第一次作业更像是对于层次化设计和一些设计模式（如工厂模式）的入门，如何把问题抽象化归一化在这一单元现得尤为重要。

第二单元

第二单元就十分明确，对于多线程的练习。线程安全、线程通信是本单元重点。其次是对生产者消费者模型的理解。关于线程安全、线程通信的实现各有不同，我采用了最简单的synchronized和对象锁以及简单的标志位通信，可能是实现的时候比较小心除了第三次作业课下出现cpu运行飘高最后发现是控制条件写错导致暴力轮询之外，好像并没有出现什么线程安全的问题。比起线程安全，这一单元给我的理解是取舍与适合。调度算法在本单元的水面上掀起了不少波纹，对于我自己来说，确实花费了不少时间去纠结这个问题，虽然最后结果似乎很是令人迷惑，但起码使我认识到，oo是没有标准答案的，同理于许多其他问题，但不断地实验尝试总会有点收获。

架构方面，吸取了第一单元的经验教训，在第一次作业就思考了作业的演进方向，并明确了各个类的分工，电梯负责电梯自身的运行，输入线程负责输入，请求队列管理输入请求。虽然在最后一次作业临时加入了电梯外的调度器，但总体比第一单元作业体验好。

第三单元

？这单元需要我动脑子想架构吗。说这单元似乎是让我理解JML，但这对于修过离散的人来说应该不难吧，如果要在理解代码的基础上写的话（实验课上）还是有一定难度的，虽然难度也集中在对代码的理解上。反而难点在于需求的实现，在于算法的选择与实现。当然这一点我并没有做好，也是我整个OO课程拿到20分的低谷发生的地方。之前没有学会的东西总会在某个时间摆你一道的，早晚而已。其次是JML的工具链，显得不那么友好，不过也无伤大雅。

第四单元

UML是个好东西，架构设计在本单元也体现出了一部分，第一部分分析过了，就不再细说，大致是适配器模式加树的建立。

整体来看，架构设计从刚开始的觉得没必要，到后来拿到题先思考后来的演进以及良好的架构实现，并学到了很多优秀的架构设计，确实是受益匪浅。

OO方法理解的演进

而对于面向对象的理解，从假期预习作业的反复琢磨怎么用上继承，到如今不自觉地用上oo的特性，总觉得很奇妙。回过头来看，我自己对于oo的理解，或许用一个词来概括——抽象，各种意义上的抽象，如何从一堆乱七八糟的东西中抽象出共性并进行统一管理，如何对看似没有关联的问题运用一致的方法模式进行处理，这都是抽象的能力。而不管是层次化、模型化或者其他，依我拙见都是抽象的另一种表达，只不过是抽象的不同实现方式。

四个单元中测试理解与实践的演进

• 刚开始的时候还是停留在手动编写测试数据上，但显然效率太低而且覆盖性不太全，于是开始合计着搭测评机。不得不承认测评机解放了人力，但测评机可测试的部分是有限的（取决于你写了多少），且对于时间的测试也并不精确。中期我过于相信自己的测评机，但后来发现数据不完备，于是采用手动+自动的方式测试。第三单元学习了Junit，也是很好的手动测评的方法，精确打击一招致命，good。当然第三单元还教会了我小黄鸭debug法，效率较低，但没办法的时候总可以用一用。

• 我觉得自己有一点非常不好，总觉得自己不可以（虽然大多数时候是事实吧），就譬如测试搭测评机，我总觉得自己搭不了不能写，其实最后写出来发现，哇我还是能写出来的，这是一种正面激励吧或许，虽然有时候写出来的东西基本没用（。

• 事实上有一点感想在于，测评机是真的香，debug是一回事，在写测评机过程中学到东西是一回事（mac与windows的不一致教我做人），在编写测试数据的时候，总会对作业有更深的理解，这点在UML这一单元体现的尤为明显。

课程收获

• 最明显的收获是，从刚开始看到题目一脸懵的小白，到如今拿到题目开始分析，将问题逐步剖析分解后开始动手处理的大白。从一开始的看到题就动手上，到如今的不思考明白70%绝不动手的懒癌拖延症。
• 其次的收获便是学会以面向对象的方式思考问题，与面向过程融合觉得有点意思
• 再次的收获是入门了两门语言，java&python，后者写对拍必备啊（
• 再再次是复习了数据结构吧，知道算法原来也是有用的？（。或许可以说是，有些东西你暂时没用到不代表它没有用，只是你还没有到用到它们的能力。
• 除了学习技能上的收获，oo给我的还有思想上的考验，比如简单问题不轻视，困难问题不慌张。以及就是，真遇到比如强测炸了拿20这种爆裂事件时，也别自闭到忘了还有课，要么只会更GG。
• 还有时间安排上......（我话好多

三个具体改进建议

• 研讨课方面，业界大佬咕咕了吗（，其实是希望能够能和处于开发一线的工作人员沟通的，这也更能使我们认识到自己所学的东西与实际应用的紧密联系，而不是仅为了完成课程知识的作业。
• （这个建议是我出于私心可以忽略orz）希望可以给强测爆炸的孩子二次机会，就像一行两行可以修复的bug是不是可以少扣一点分啊啊啊啊啊啊（好的dbq我知道我在想peach。真实可行一点的话就是，或许第三单元中测能够提高难度吧，虚晃一刀太狠了。
• 希望能给架构好的设计多一点奖励，在此基础上稍稍放宽对于时间性能上的限制，可能会增加助教的工作量呢（x
• 在某一单元结束后在向助教要优秀代码的时候了解到，老师说本单元没有令他满意的架构设计（？好像是这么说的吧），那么老师是否可以在课程结束时指出什么是优秀的架构并讲解呢，我们自己摸索当然没有问题，但是如果真的摸索不到，希望还是能有老师的指导。
• 还有互测时提交数据，如果数据非法能不能给出非法理由呢，大量时间花费在找自己数据为啥非法（最后还没找出来）真的有点难受。

线上学习oo课程的体会

• 事实上对于作业来说，线上是完全没影响的（能有什么影响？），交流的话，其实在学校能交流的也就那么几个人，真想交流也不缺工具，关键还是想不想做不做的问题。
• 如果真要说有影响，实验跟研讨课是有一定影响的，起码对于我来说，以腾讯会议为主要形式的研讨课不如正面交流来的愉快（毕竟不熟悉），实验的话虽然时间拉长，但网络的问题与题目理解实在难顶。
• 对于我个人而言，理论也是有一丢丢影响的，我个人更喜欢面对面交流，并能及时跟老师私下探讨问题（毕竟问题太弱智不好意思在群里问orz）。
• 但是，但是，划重点，老师跟助教可真是太好辣，总觉得吴际老师看着我们一群菜鸡但是总是带不动的无奈之感都要溢出天际了。
• 十分感谢各位老师、助教的付出，手动比心。