BUAA_OO_2020_Unit4_Summary

BUAA_OO_2020_Unit4_Summary

目录

• BUAA_OO_2020_Unit4_Summary
  • 第四单元作业架构设计
    
    • 工厂模式+适配器模式
    • 基于度量的程序结构分析
  • 四个单元中架构设计及OO方法理解的演进
  • 四个单元中测试理解与实践的演进
  • 课程收获
  • 三个OO课程的具体改进建议
  • 线上学习OO课程的体会

第四单元作业架构设计

 第四单元作业的重点为：基于对UML图组织元素之树状结构的理解，重建便于查询的数据结构，并基于此结构设计相关的查询算法。

工厂模式+适配器模式

UML图以树状结构组织元素，而原始构造方法为我们提供的便是这样组织的，但这样的数据结构并不便于实现对于图中元素关系的查询。

因此我采用了适配器模式，将原始元素封装为一个保存有实现查询算法所需各种信息的适配器类。

以UmlClass的适配器类MyUmlClass为例：

在适配器类中，通过根据查询算法所需信息引入对应属性，实现了UML图中元素的层次化、关联化管理；基于这些属性及对应算法实现查询方法，以提供查询功能接口。

而根据原始元素构建相应适配器类的过程，我使用了工厂模式（引入Builder类），首先解析元素类型生成相应适配器类，再调用链接方法向适配器类中填充相关信息。

最终三种UML图被抽象为三种对应的适配器类，在最终交互类中调用其提供的查询方法即可实现查询功能。

基于度量的程序结构分析

由于本单元三次作业的迭代开发中，新增功能均不影响已实现功能，基于作业架构，我的后续迭代开发均未修改之间的内容，故在此仅对第三次作业进行基于度量的程序结构分析。

UML类图如下：

观察类图可见，基于UML图中各元素的层次关系，我为每一类元素均增加一个适配器类的做法存在冗余工作，对于底层元素类并无必要。

方法复杂度如下：

复杂方法主要集中在工厂模式构建适配器类以及复杂度较高的查询方法。

类复杂度与相关方法复杂度分布规律基本一致，不再贴图。

依赖矩阵如下：

包内依赖比较严重，层次比较清晰。

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

架构设计

• 第一单元——初识迭代开发
  • 架构混乱在面对新需求时的难以适应是OO教给我们的第一课，我的OO生涯便是从第一单元三次作业间的重构开始的。由一锤子买卖，AC完就走人的面向过程到三次作业层层迭代的面向对象，第一单元的重构历程虽然痛苦，但却向我展示了所谓架构之于工程化开发的重要意义，也让我在写代码时将首要工作放在架构设计上。
• 第二单元——架构可扩展性的SOLID原则
  • 在第二单元迭代开发的过程中，课程组更深入的为我们讲解了所谓架构优劣的评判标准与设计方向，那便是SOLID原则。单一职责原则、开放封闭原则、替换原则、接口隔离原则、依赖倒置原则，经历了这五种原则的学习，我不再像第一单元初识架构时那样全屏灵感设计架构，而是学会以系统的步骤去设计、去衡量。
• 第三单元、第四单元——优秀架构的构筑展示
  • 在第三单元与第四单元的迭代开发中，我们在架构方面所付出的精力大大减少了，而这得意于JML规格的有力帮助以及UML架构的合理规划。在这两个单元我见识到了优秀的架构设计方法，亦体会到了其带来的优秀的开发体验。

OO方法

• 第一单元——工厂模式、高内聚低耦合
• 第二单元——多线程、设计模式
• 第三单元——基于JML规格进行开发
• 第四单元——基于UML理解程序架构

如上所示，每走过一个单元，我都能学习到让我眼前一亮的OO方法，随之积累的理解亦成为我架构设计中填充的内在。

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

• 第一单元、第二单元——黑盒自动测试的绝对领域
  

  • 测试无疑是迭代开发过程中最为重要的环节之一，而这也成为前两单元作业的一大难点。受教于课程组的提示及大佬们在研讨课上的分享，我在OO学习得起点便开始了搭建自动测试机的探索。

    自动测试机的搭建大致分为四个步骤：测试数据的随机生成，输入输出的重定向，运行结果的正确性检验，以及将前三个步骤串联重复的批处理运行。

    这四个步骤可谓集一年来所学知识之大成，从python中各种相关库的使用、计算机组成中所学有限状态机在正确性检查中的应用、操作系统课程中的批处理作业及重定向方法……一次次搭建自动测试机的过程都收获满满。

    而在前两个单元这种测试数据存在生成规律、运行结果正确逻辑可自动化检验、而人为构造数据局限性较大的情况中，黑盒自动测试对于程序的检验真的真的真的十分高效！！！

    当然，黑盒测试对于边界数据的覆盖性并不敢让人彻底放心，很多极限数据还是要人为构造的。

• 第三单元、第四单元——白盒测试的构建方向
  

  • 在第三单元和第四单元中，课程组向我们普及了很多测试单元，为我们进行白盒测试提供了方向，使我们在黑盒自动测试之余，手动构造测试样例时不再仅凭灵感瞎想，而有了一套覆盖率较高的构建方向。

    而在第三单元和第四单元这种运行结果正确性不好自动化判断的情况下，与同学对拍成了黑盒自动测试的可行构建方法。

    经过一个学期OO课程的洗礼，白盒+黑盒的测试模式已成为我开发程序时不可缺少的重要步骤了！

课程收获

封装思想、优化策略、架构设计、测试方法，这便是OO课程带给我最大的收获。

如以上两节所言，架构设计和测试方法带给我的收获满满，已成为我后续程序开发中开篇与收官之要。

而OO课程带给我的另外两大收获为封装思想和优化策略。

封装思想对于工程开发的意义类似于架构设计，他体现在在架构设计的底层实现上，是面向过程和面向对象的本质区别，见识过封装思想后，已经很难再回到面向过程的开放方式去了。

而优化策略带给我的收获并不是一个个复杂的算法，而是在进行优化时所遵循的重构过程，尽可能地少重构，尽可能地不去影响已经完成的代码，在架构设计上留足优化的空间，处处都是学问。

三个OO课程的具体改进建议

• 理论课应注重与作业的联系
  

  • 所谓“纸上得来终觉浅，绝知此事要躬行”，本学期的理论课对于讲述知识的具体实现往往仅对最基本的知识点进行简单讲述，而将大部分精力放在宏观知识体系与框架的叙述上。

    体现在学生的学习过程中，那便是每次写作业总要回去翻看理论课视频，而又发现视频中并没有什么干货，最后只能自己搜集资料学习，一个学期下来，学到的东西很少来自于理论课上。

• 实验课的难度设置应该更为合理
  
  • 本学期的实验课总是让人胆颤心惊，一部分原因在于实验课难度飘忽不定，有时需要延长时间才能完成，有时又简单的让人怀疑人生，体验不佳。
• 优化实验平台的抗压能力及提交冷却时间
  
  • 实验平台在高压力环境下运行效果太差，搞人心态，实验课提交的冷却时间设置亦不太合理，既然没有实时的结果反馈，设置5分钟之长的冷却时间有什么意义呢？

线上学习OO课程的体会

就OO课而言，线上学习对我来说比线下学习体验更佳，因为这门课程的学习方式决定了学生需要更多的时间通过网络资源自主学习，通过社交平台进行社区交流。在助教们辛苦维护评测机、更新指导书、及时解答题问的情况下，这学期的线上学习体验很好。