第四单元总结与OO课程总结
前言
完成这个博客OO课就结束了。虽然没有那么尽善尽美，但我确实在课程中学到很多，一个学期的努力没有白费。
博客分为以下几个部分：
- 第四单元架构分析
- 课程总结
- 架构设计思维及OO方法理解的演进
- 对于测试的理解与实践的演进
- 课程收获
- 改进建议
第四单元架构分析
本单元作业在设计之初参考讨论区大佬的帖子，设计思路主要有以下两方面：
- 分层读入。由于
UML图不保证元素的出现顺序，且下层结构依赖于上层结构，因此可以对传入的UmlElement数组进行多轮遍历，按照层次结构自顶向下读入并识别元素。 - 自定义对象。原本官方包中定义的诸多对象在实现某些功能时会较为麻烦，我们可以自定义对象，其中包含对应的原生
UML对象的实例，同时添加一些参数使计算方便。
写代码之前务必搞清楚UML类图，顺序图，状态图内部的层次结构。第四单元训练中下发的手册以及老师上课讲的PPT都是十分有用的资料，尤其是有关顺序图和状态图的部分，手册里一层一层剖析结构，几乎是手把手教学，在本单元的学习中起到非常大的作用。
具体到作业：
第十三次作业仅包含类图，分三轮读入。同时我为UmlClass, UmlInterface, UmlAssociation, UmlOperation都建立对应的自定义类，并添加一些参数管理元素间的关系。比如UmlClass对应的自定义类MyClass，其中包含father变量用来指示该Class的继承关系。指令方面，需要仔细阅读指导书中对一些关键字的定义，抛出异常的条件以及对特殊情况的说明。
第十四次作业新增了顺序图和状态图，在弄懂结构的基础上做起来并没有遇到什么大的问题，这一次分五轮读入，由于图的种类和指令数都有所增加，如果还将所有的功能都写在一个实现类MyImplementation中，很可能会超过chekstyle的限制，且代码会很臃肿。因此我将三种类别的图分开处理，如下图：
读入元素后将其存储在对应的ClassDiag(类图), SeqDiag(顺序图), StateDiag(状态图)中，将有关指令也在这些类中实现，需要查询哪个指令就调用对应类中的方法。
第十五次作业新增模型正确性检查，依然是在对应的类中实现指令，查询时直接调用对应的函数。这一次作业难在对指令的理解(其实前几次作业也是如此)，自然语言的表述方法不可避免地会产生歧义，有些规则还需进一步由助教确认。
课程总结
架构设计思维以及OO方法理解的演进
不得不说pre这个环节非常重要，初次接触面向对象的设计思维时真的需要引导，思维这种东西就是会者不难，不会者难以理解。充分学习有关的知识，辅以一定量的训练，对建立起整个思维模式起到关键性的作用。
面向过程到面向对象，我自己的理解可以用以下这个例子来说明：假设现在楼下有一桶水，需要搬到三楼去。
面向过程的思想侧重于解决问题的过程，如何把水搬到楼上？可以一个人扛，可以两个人抬，可以坐电梯，等等。而面向对象的思想是将构成问题的事物，抽象成若干个对象，建立对象的目的不是为了完成一个步骤，而是为了描述某个事物在解决问题过程中的行为。我可以找到三楼订水的那个兄弟，告诉他水到楼下了，剩下的交给他，我要描述的就是这个人搬水的行为。
适应了面向对象的思想之后，我们开始接触到一些常用的设计模式，比如第一单元可以使用工厂模式，抽象工厂模式创建对象，第二单元使用单例模式，生产者消费者模式保证线程安全，使用观察者模式解决多个对象关联的问题。这些设计模式本质是软件开发过程中的优秀经验，合理地运用设计模式可以完美地解决很多问题，保证代码可靠性。
再往后的重点就从面向对象本身移开，转而关注架构设计与代码测试。第三单元根据规格实现代码，为程序事先确定一个框架可以事半功倍。课上讲解的契约式编程思想也是着眼于代码的总体架构设计。第四单元的类图也是差不多的思想，只不过是将代码想结构以UML图的方式表现。
对于测试的理解与实践的演进
我自己评价，我在代码测试这方面做的工作是比较不足的。由于课业压力以及其他种种原因，我的测试部分一直不尽如人意。曾经想要尝试自动化测试，写过非常粗陋的对拍程序，最后因为坚持不下去而告终，对于测试模块的编写也只能选择一些极端情况，覆盖率欠佳。
不过好在在OO课中终于结束了手工测试的时代，开始实践一些(半)自动化测试，比如自动生成测试数据，使用一些工具包测试运行结果。测试对于一个程序来说是寻找bug的有力工具，做好测试可以少走很多弯路。
当然，有些问题最好还是在写代码的时候就避免，不然很容易出现做了一天的测试，结果可能只是因为一个数写错的崩溃情况。
课程收获
显而易见地，我学习了面向对象的思想，对于行为主体的抽象，学习了很多设计方法，了解多线程编程，了解程序的测试，对架构设计有了更加清晰的认识。
除了以上这些，我觉得有些东西真的是潜移默化的在影响我的编程习惯。比如现在写代码永远是先思考后下笔，不想好架构就很别扭。再比如那句人人皆知的"高内聚低耦合"，仔细想想其实就包含在很多设计模式中。甚至现在写文档还总会想到写OO博客的事情。虽然我可能没有完全接收到课程组想要传达给我的知识，但我相信随着后续对于程序设计的实践，很多现在感觉不到的东西都会慢慢发挥作用。
改进建议
- 首先是
pre的设计，我认为这种课前训练可以出一些选做的难题，并提供相应的参考答案，就像每单元的training一样。夸张点说，现在的pre设计就像是告诉大家1 + 1 = 2, 然后实际的作业是做微积分。当然课下自己去学习也很重要，不过出点难题既可以指明思路，也可以给同学们验证学习成果，还可以学习答案中的架构设计。再者pre是假期期间的工作，假期多了解点知识，开学之后的压力会小很多，毕竟开学那几周事情太多了，突然做这种有难度的作业很难顶。 - 其次是互测，我认为互测最需要的不是想办法找别人的bug，而是阅读别人的代码，对比自己的工作，找出各自的优缺点，总结经验，有时候看到一份优秀的代码真的会让我这种菜鸡有种眼前一亮的感觉。这里我建议延长互测时间，让大家可以在充分阅读别人的代码的基础上进行问题分析。
- 最后是理论课，一周一次的理论课总是给我一种割裂的感觉，像是游离于OO课程之外自成一体。但是理论课讲的确实都是干货，感觉是课程的组织安排上出了一点问题。相比之下今年的研讨课非常优秀，大家一起交流的氛围很好，也能学到很多东西。
到此OO课程画下句号，这门课真的是从上到下充斥着课程组的心血，感谢老师与助教们的辛勤付出。天下没有不散的筵席，课程虽然结束，但学习永无止境，共勉。
标签：总结,OO,代码,面向对象,课程,测试,单元 来源： https://www.cnblogs.com/135qaz/p/16403804.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。