OO完课总结

本单元两次作业的架构设计

第一次作业

根据大佬给出的UmlElement类型使用指南，先自行理解了用 java模拟uml的原理，并依照原理进行了代码编写，下面是第一次作业的架构设计。

首先是作业要求实现的两个类，分别是main类以及继承UmlInteraction的MyUmlInteraction类。MyUmlInteraction里面实现了UmlInteraction要求的所有函数。

MyUmlInteraction直接对应一个Management类，负责保存与整理所有的输入数据。所有读入的数据在Management里面先按类型进行归类，并保存在对应的一个id到结构体的HashMap中。例如

private HashMap<String, UmlAssociation> umlAssociation;
private HashMap<String, UmlAssociationEnd> umlAssociationEnd;

下一步是数据处理。将每一个数据归到它应该所属的类中进行管理。因此，对于需要管理其他数据类型的类型，我新建了一个类用于保存其下设的数据，即MyUmlClass类和MyUmlOperation类。接下来遍历每一个数据，把它归类到对应的MyUmlClass或MyUmlOperation中。例如将UmlParameter归类到对应的MyUmlOperation中，将UmlAttribute，UmlAssociationEnd类归类到对应的MyUmlClass中。

接下来只要完成查询功能即可。查询功能的实现即先在Management类里面将UmlClass的name转换为对应的MyUmlClass。所以两个异常均在Management查询中抛出。得到对应的MyUmlClass或者MyUmlOperation后，剩下具体的查询均在这两个类内进行。即直接查询这个类下所管理的数据。例如

@Override
public int getClassOperationCount(String className, OperationQueryType
        queryType) throws ClassNotFoundException, ClassDuplicatedException {
    MyUmlClass thisClass = management.getClass(className);
    return thisClass.operationCount(queryType);
}

第二次作业

关于顺序图和状态图的查询方式跟第一次作业相同。这两种图的数据分别由SequenceManage和StateManage进行管理。将不同图数据分开放置，减少检索时间，类长度与复杂度。

关于类图的三个Rools使用深度优先遍历。由MyUmlGeneralInteraction调用各个Management来实现。

（最后面因为时间问题也没能实现）

四个单元中架构设计及OO方法理解的演进

第一次作业

多项式求导。我从最开始还依赖有限状态机这种很面向过程的算法，逐渐开始考虑是否将项提取出来当作一个类，是否要将表达式提取出来。当时我的理解还不够深入，分的类还很少。不太理解为什么老师说要把XXX当成一个单独的类，在我看来好像没必要？我就仅限于把类似功能的函数都提出来丢在一个类里面，仅此而已。当时甚至还不太会继承和接口（捂脸）。

第二次作业

电梯调度相关。第二次作业我在设计的过程中就开始有所思考了。什么样子的可以作业一个单独的对象提取出来，什么样的可以放在一起。我记得我从第一次课下开始就有了elevator类。然后惊讶的发现，后两次的练习中的一些扩展功能都可以直接修改这一个类，再新增一些功能即可。已经完全不是第一次作业中，写一次作业就要重构一次的情况了。也算是不小的提高了吧。

第三次作业

地铁算法相关。这一次作业感觉题目本身就很面向过程，妥妥的数据结构还债呀（滑稽）。我在这一次作业里面，更多的是考虑用何种数据结构，何种算法更加合适，并考虑图算法应该归在哪一个类当中去完成。在这一次作业里，我基本把java主流的数据结构都学了个遍，也用得非常的熟练了。不过我又回到了第一次作业里面写一次就重构一次的尴尬状况。因为数据实在是太多了，让我非常混乱，数据管理也是我自己在设计架构的时候没有很注重的地方吧。吃一堑长一智。

第四次作业

UML模拟相关。这一次作业的要求理解了之后发现好像并不是很复杂。虽然数据本身挺多种类也很复杂，但是本身就很有规律，所以这一次作业里面我的数据管理还是很有条理的。我发现管理好数据之后问题就会变得很简单，就只是一个从哪里去提取查询的问题了。这应该算一个从第三次作业过来的一个提高吧。

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

关于测试方面，我很羞愧的说，这可能是oo课程中我做得比较少的方面了。第一次作业还比较简单的时候，我是会去阅读别人的代码，然后根据代码提出针对性的测试数据。那个时候的测试数据只是针对某一个人的。但是到第二次作业开始，代码变得复杂，时间也变少了，实在是没有办法一份一份代码去阅读。就开始使用群测的测试方法。即编一份数据直接跑七遍，看有没有人出错。再到后面在讨论课上听闻大佬的自动化测评方式，感觉十分心动，奈何我还不太会，现在考虑在暑假自己研究一下，在以后的学习工作中肯定还要用得上的。

课程收获

通过11次project和4次实验课的实战练习，我深入了解了面向对象要如何实际操作，也能写出一个像样的面向对象的代码。给我最大的感触就是，感觉学习java在寒假就已经学得差不多了，经过这一个学期，表面上看起来好像什么都没有学到，还是在写java代码，但是却学到了很多纯理论学不到的东西。现在我已经能够用一种oo的思想进行设计架构并且完成一个少有bug的代码。oo这门课给我最大的感觉就是练习了，不像是学一大堆没什么用的理论知识，而是交给我们一些能够实用的东西，通过大量有序有节奏有安排的练习来真正提升我们的代码能力。

另一个收获很大的地方就是课程组提供了相当多的机会让我们欣赏（%）到了大佬们的代码。包括讨论区大佬的精彩发言，讨论课上的分享还是直接给我们一些好的代码范本。这是让我真正有所提高的。一个人写代码再怎么样也是闭门造车，看不到真正写得好的代码是什么样子。阅读大佬的代码和思想，才能够看到之间差距的鸿沟，拥有前进的动力和榜样。

三个具体改进建议

1

建议实验课不要放在第一次正式上课之后，要不然刚了解完一个新东西，就要马上考试感观很不好，最后还是变成了需要提前一周开始自学，失去了上课的意义。应该是第一次课和第三次课为讨论课，第二四节课上机会更好一些。

2

建议一个互测屋里面人数可以适当减少一点点。八个人意味着要看七份代码，很难有时间认认真真把他们的代码全部看完。所以很少会根据代码针对性的给出测试样例，大多数时候都是在盲狙。编一份样例看看能ban倒几个人。我知道上个学期是两人互测，这样有充足的时间和精力看透一个人的代码，但是这样借鉴意义还是少了一点。建议互测屋能够维持在3-4人左右，给想看别人代码的同学有一个好的机会。

3

建议多提供一些好的代码。可以以加分的方式请大佬们提供他们好的代码。请他们将自己写得好的，很有面向对象思维的代码整理注释一下，然后通过自荐，向其他同学进行展示。让我们能够通过同一道题切身了解到什么样子是一个oo的，规范的，严谨的，好的代码风格，代码架构，代码思维。不只是看互测屋里面跟我同水平的带啊吗，更是可以向大佬学习，这样感觉练习起来更会事半功倍。

总结

真心感觉面向对象课是我上过的收获最大的编程课之一了，并没有学长学姐传说中的那么魔鬼，与小伙伴们相互扶持着就这么过来了，这离不开助教大大们的辛勤付出，在这里感谢陪伴了我们一学期的超级厉害的助教大大们。在这门课中，度过了有开心有难过的大二时光，谨此纪念。