OO总结

1、总结本单元两次作业的架构设计  

作业一

在本次单元的作业中，主要是对于输入的UML图进行相应的解析，存储相应的信息，输入指令，并获得相应的类图，顺序图等信息。

作业一

本次作业难点主要在于理解好类图中的相应的关系——继承，关联，实现等等，比较难理解的便是各种类型元素中parent_id的含义。而为了能够更加清晰地理解各类元素中的相应关系，利用start_UML可以更加理解。

而在本次作业中，我对对输入的element进行相应的解析，然后主要利用HashMap来存储相应的信息。

    private HashMap<String, ArrayList<UmlElement>> allParameterOperation

            = new HashMap<>();

    private HashMap<String, ArrayList<String>> association = new HashMap<>();

    private HashMap<String, String> classid2Associationend = new HashMap<>();

    private HashMap<String, ArrayList<String>> interfaceRealizationofClass

            = new HashMap<>();

    private HashMap<String, ArrayList<String>> interface2parentinterface

            = new HashMap<>();

    private HashMap<String, ArrayList<String>> parent = new HashMap<>();

    private HashMap<String, ArrayList<String>> associationName =

            new HashMap<>();

主要用于存储属性，操作，父类等。

对于参数的储存，需要判断其类型，存入相应的HashMap,键值为operation_id,分为not private(not hidden),all等，用于存储相应的属性id。

    private HashMap<String, ArrayList<UmlElement>> notHiddenattrofClass

            = new HashMap<>();

private HashMap<String, ArrayList<UmlElement>> atrofClass = new HashMap<>();

而对于operation需要判断存储相应operation的参数，根据参数的direction将参数分为noReturn类型和return类型即可实现对操作的判断。

 

 private HashMap<String, ArrayList<UmlElement>> noReturnParameterOperation

            = new HashMap<>();

    private HashMap<String, ArrayList<UmlElement>> returnParameterOperation

            = new HashMap<>();

指令最复杂的是获取父类及自身的各种关联，实现等。

而对于这个主要在于存储UML_GRENERATION类型的元素，存储好source and target,对于类进行深度优先搜索，对于接口进行广度优先搜索，即可实现相应的操作。

此次作业将各类信息都在myUmlinteration中实现。

优点在于信息获得容易，代码量少，但是缺点不言而喻，仍旧是一种面向过程的代码实现，屎山一样的代码，第二次作业可谓是一个悲剧。

 

 

作业二

第二次作业，由于又增加了时序图，状态图类，于是我建立了状态图，状态图解析类。而本次作业中难点在于循环继承，重复继承，以及对端与类的属性相同等问题。

对于类的对端与类的属性相同的问

利用HashMap存储好对端和类的关系即可实现

重复继承

获得每个类和接口所继承或实现的接口列表，判断是否有重复出现的接口即可。

循环继承

利用广度优先算法，判断搜索的类是重复出现即可

在前一次作业的基础上主要增添了时序图和状态图的解析问题

UML类图如下

 

 

类图可以看出在myUmlinteration中操作过于多，没有彻底地实现抽象出对象。

 

 

 

 

 

可以看出检查规则的三条指令的复杂度高，主要在于需要利用到父类HashMap,关联类，元素名称和元素id的对应关系等等。

（2）总结四个单元中架构设计及OO方法理解的演进  

第一单元——多项式求导

初始接触oo时，还留在寒假时布置的几道加法题中，感觉和c语言，和python没啥子大的区别，似乎就是另一种类似的语言。但经过老师的层层引导，渐渐似乎懂了那么一点小意思。

对于第一单元作业中，老师一直强调需要构建多项式类，三角函数类等，初始觉得，这不太费劲了，直接判断利用求导法则不就ok了嘛？但随着要求逐渐提高，发现原始的面向过程实在是有点挑战自己的智商，不一会就糊了，不知道自己在写什么。而建类的方法这种“低内聚 高耦合”的方面则能够在一定程度上提高代码的可读性，使自己的思维更加清晰，对于代码的修改更加方便一些。

在此单元作业中除了求导之外，WF问题也一直困扰着我们，我们一直在纳闷，为啥要输这么多WF的数据，这不是没事找事吗？完全考的不是重点，还戏谑为面向WF课程。当然没有血与泪的教训，我们无法切身地明白WF的重要性。但荣老师在课上提到的载人火箭各种灾难，也让我们在一定程度上明白了“不要相信别人”。

第二单元——多电梯调度

这是我觉得最神奇的一个单元，就像已经在实现现实生活中的事物，感觉这些代码不再是那些看似令人头痛的代码，而像是一个实体，编写代码时就感觉自己心中有一个电梯在不断运行。

当然这个电梯也不是好惹的，在这单元中调度器这一线程由于过度抢占cpu时间导致的cpu_run_time_error问题，让笔者在强测中t了一大片，可谓是血与泪的教训。

笔者认为多线程最主要是明晰生产者消费者模式中共享物体的互斥问题，最主要便是哪些是共享物品，什么时候需要互斥，其余实际上和平常的代码没有太大的区别。

第三单元——图管理系统

荣老师告诉我们，接下来的单元非常的简单，对比于第二单元简直就不是一个数量级的，我们信了。然后，就变成了数据结构的应用问题，图的维护问题，可以说是非常简单（tongku)了，前有WA,后有tle,哭唧唧。

但是这次作业同样也让我对oo的理解加深了不少，现实生活中的确很多地方需要响应时间短，轻则给用户带来不好的用户体验，重则则会由于消息的不及时导致无法及时响应，最终导致惨剧，于是中间结果的存储将十分重要。

第四单元——UML解析

本单元作业中，主要在于各种类的建立，实际上已经类似于一个小型的应用了，需要有良好的鲁棒性，可扩展性，在第一次作业中着急下手，程序的性能不好，只能自己能够看懂的代码。第二次在分析下，建立了新类，略微有点面向对象的雏形，当然也仍需不断不断地改进，不断不断学习大佬的代码。

（3）总结四个单元中测试理解实践的演进

测试主要依靠人工测试，虽然大佬们说的对拍器非常地优秀，但人工测试能够在一定程度上加深自己对实验的理解（也有自己太懒，不愿学写评测机的原因）。

第一单元——多项式求导

主要在于WF问题，由于化简问题导致的WA问题。

WF问题需要琢磨清楚规则，构造复杂的多层嵌套即可。

WA问题需要将常见的化简类型sin2(x)+cos2(x)等进行构造，往往会有出乎意料的效果。

第二单元——多电梯调度

主要在于换乘问题，换乘人进入离开不同电梯先后问题，超容量问题人数的投放问题，课程组提供的工具能够很好地检测到Cpu运行时间，使得cpu时间更加可视化，也让我们对多线程的执行情况有了大致的了解。

第三单元——图管理系统

主要在于对图进行修改之后的维护问题，全部舍弃or修改不足都会导致出现问题，于是测试的中心在于对图进行增删改之后的查询是否出现问题。

第四单元——UML解析

此单元同样构建了复杂的时序图，状态图，以及类图，通过和小伙伴对拍的形式，找出了不少的错误，测试点覆盖每一条指令。

最复杂的便是3条rules规则的判断，在架构时想出对应的例子不仅能够使得元素之间的关系更加清晰，同样能够使得后续的debug之路不至于江郎才尽。

当然，通过中测，强测，互测抑或bug修复，都不能表明程序中已经没有bug了，课程组的中测数据普遍比较简单，过了中测并不能代表什么，笔者有过就过一个强测点的惨痛经历。同样的，在将来的学习抑或是工作中要抱着这一信念，我的代码还有bug,我觉得还能再拯救一下。

（4）总结自己的课程收获

一学期的oo课程终于结束，无数的坑等着我踩，其中有发脾气暂时放弃oo的痛苦,也有一整天坐在电脑前着代码的苦逼，也有写着写着发现不对劲，重构的无奈。

当然回首才发现自己学会了很多，面向对象的思想正慢慢渗入我的思想中，正则表达式的运用，继承，接口，各种模式的明晰（虽然没怎么使用过），建模语言的简单运用，UML语言的简单使用……种种，令人受益匪浅。

当然仍有很多不足，各种继承，接口的熟练运用，模式的真正了解体味，代码风格只有在临交时才进行修改……这些总总仍需要我不断改进，学习。

（5）三个具体改进建议

1、互测看别人代码实在太致命了，建议之后要求同学交一个readMe抑或是简单的注释。

2、bug修复有时有点晚，在被驳回的情况下容易被人遗忘。

3、研讨课可以让大佬拿着自己的代码，进行简单的分析。

最后，衷心感谢oo课程组的优秀的老师和助教们，你们辛苦了！看到助教们提供的各种包，真的非常感动，再说一遍，你们辛苦了！

 

转载于:https://www.cnblogs.com/ytzhang/p/11077439.html