第四单元总结暨结课总结

目录

• 第四单元架构设计
• 学期架构总结和 OO 方法理解
• 学期测试理解与实践
• 课程收获
• 改进建议

一、第四单元架构设计

• 类图和数据分析：

  • 第 13 次作业：
    
    

  • 第 14 次作业：
    
    

• 架构总结：

  • 第 13 次作业和第 14 次作业的架构整体上类似，均为对每种 UML 图建立一个专门处理的类，在类中包含构建描述该 UML 图的属性的方法和提供查询接口的方法。
  • 架构整体上更偏向于面向过程的方式，包括使用 Map 存储 UMLClass 和 UMLAttribute UMLOperation等等的映射（并没有采用树状结构或是单独构建一个类来表达一个完整的 UMLClass 或是 UMLInteraction 等），和构建 Map 的方式。
  • 这个架构的“好处”可能是：
    • 不用花很多时间构思架构的设计。
    • 代码编写所消耗的时间比较短（但 Debug 的时间可能会很长）。
  • 这个架构的劣势是很明显的：
    • 我的程序中一旦出现 Bug 就会很难定位和修改，事实上在写第 14 次作业的时候也正发生过这样的情况。
    • 同时反复调用 Map 的 get() 方法，程序的时间复杂度比较高。

二、学期架构总结和 OO 方法理解

• 架构总结：

  • 回看我们四个单元的作业，每个单元都是在给出基础需求的情况下，不断给出新需求和要求的新功能进行迭代开发（有点类似持续集成，但开发强度没有可比性），其实这也是逼迫我们采用面向对象的编程手段和一定的设计模式。
  • 因此架构设计就需要尽量能够满足“开闭原则”，以便在原有基础上扩展新需求，同时尽量少得重构原有代码。事实上，很多已有的设计模式都是在此基础上，针对不同的需求模型进行扩展的。
  • 课程组为什么希望我们能够掌握一定的架构设计技巧，避免大量重构呢？
    • 首先，重构会修改很多原有代码，同时破坏代码之间的一致性，需要消耗很多时间去重新思考整个完整的任务，效率低下。
    • 同时，在原有代码比较多的情况下，由于粗心或者种种原因，重构的时候很有可能会破坏原有代码的正确性，比如说某个方法的先验和后验条件变化了，但相应的调用者却没有修改，这就很有可能导致程序的逻辑错误。
  • 第一单元架构：第一单元由于刚开始接触面向对象编程，对于设计模式还不够熟悉，架构设计上显得比较粗糙。我主要采用了装饰者模式去优化和复用求导逻辑，但是由于整体结构设计耦合度依然较高，同时需求变化比较大，每次作业依然会重构相当部分的代码，尤其是输入输出方面。
  • 第二单元架构：第二单元主要关于多线程，在这方面采用的设计模式主要是生产者-消费者模式，用于解耦消息传递和匹配生产者和消费者的处理速度。其余的就主要是电梯、调度器的建模问题，不涉及很具体的架构问题。
  • 第三单元架构：第三单元主要关于规格化设计，在这个单元我在架构方面投入的比较少，主要是关于算法方面投入得更多一些，在这里就不赘述了。

• OO 方法理解：

  • 什么是面向对象？什么是面向对象方法？许多关于面向对象的书籍都说面向对象是利用封装、多态、继承等概念来构建软件的一种编程模式。
  • 封装、多态和继承以及更多的诸如接口实现、消息传递的概念大家都已经很熟悉了，这些方面其实大体上都是代码在设计和编写过程中采用的一些方法。我们通过利用这些方法，以及建立在此基础上的许多设计模式来降低代码的耦合度，提高代码的可维护性，便于团队开发。
  • 但是软件工程不仅仅只是编写代码，它还包括了测试、自动化构建、依赖管理、持续发布等等一系列内容。这些方面的内容也十分重要，也有很多出色的工具需要我们去学习，包括 JUnit、 Maven、 Gradle 等等。

三、学期测试理解与实践

• 对测试的理解：

  • 课程组的测试主要采用公测 + 互测的方式进行，测试的主要目的是找出同学们的代码在具体实现过程中出现的错误，但是难以找出设计上的缺陷。

• 实践：

  • 我的自我测试主要采用两个阶段。
  • 第一阶段使用 JUnit 进行测试，主要检查测试代码覆盖率和运行时数据的正确性。
  • 第二阶段采用随机数据生成器和自动化评测的方式进行黑箱测试，随机高强度数据能够基本覆盖各种可能出现的情况，因此在第二阶段测试完后，除非是发生了题意理解上的问题，否则基本不会存在 Bug 了。因此，在采用了这种方式的情况下，我在公测和互测中均表现良好。

四、课程收获

• 在这个学期的 OO 学习中我学到了很多知识，不仅仅局限于具体代码的编写上，还包括很多相关工具的使用：
  • 代码风格
  • 正则表达式的使用
  • 一些常见设计模式的使用：策略模式、装饰者模式、工厂模式、观察者模式等等
  • 多线程的设计模式和线程安全问题
  • JML 规格
  • JUnit 测试单元
  • Maven 构建工具和 Gradle 构建工具
  • UML 图
• 上面列举的收获都是一些很具体的知识，但事实上我还有许多思想观念、对面向对象的理解上的收获，这些收获甚至更加珍贵。
• 同时，在实现各个作业的时候与其他同学的讨论也让我了解到了更多的设计思路和代码编写的方式，而且也认识了更多的大佬，这点也让我感到非常开心。

五、改进建议

• 关于 UML：理论课上所讲的关于 UML 的知识和课后作业所需要的相关知识有一些脱节，课后作业涉及了很多与 StarUML 具体实现相关的问题。同时理论课上关于 UML 的一些概念讲的不够完整，比如时序图的消息类型、组合片段等等
• 关于 JUnit：JUnit 事实上是一个很有用的测试工具，我们的课程也有提到过它，并且老师也在课上多次建议同学们学习使用。但是课程却没有比较详细地介绍这个工具，我非常希望能够在课堂上听到老师对这个工具有更多地介绍，学到更多相关的使用技巧。
• 关于多线程：个人感觉课堂上对多线程的介绍还是少了一些，可能是由于课程安排的原因（只有一个单元），许多多线程会涉及到的问题都匆匆带过了，比如说 volatile final 关键字，Java 1.5 以后的锁的机制、Java 内存模型等等。这些都是谈及线程安全很难绕开的问题。尤其是在这些方面，网络上的博客良莠不齐，说法很不统一，因此就更希望能够在课堂上得到老师关于这些问题的比较权威的解答。

标签：架构,结课,代码,作业,总结暨,UML,设计模式,单元
来源： https://www.cnblogs.com/Nemory/p/11073468.html