OO第四单元与期末总结
- OO第四单元与期末总结
- UNIT 4 架构设计
- 第一次作业
- 第二次作业
- 第三次作业
- 架构设计以及OO理解的演进
- 测试的理解与实践的演进
- 课程收获
- 课程建议
- 线上学习体会
- UNIT 4 架构设计
UNIT 4 架构设计
第一次作业
这次作业只涉及类图相关的元素.
我将所有UmlElements进行了封装，根据元素之间的关系(StarUml的组织结构)对各类Wrapper进行组织与管理.
这么做有几个缺点, 首先是编码繁复, 如果追求统一性, 可扩展性, 会造成很多的代码冗余, 真正关乎逻辑的代码很少, 大部分都是各类信息的获取与设置. 其次是存在没有必要的很多内存占用, 这一点显而易见, 解决办法也很简单, 只保存相应的索引序列即可, 不过相应的会增加出错的可能性.
优点就是完全与StarUml的组织结构相同, 杜绝了抽象的UmlElements概念, 之后的各种操作的逻辑可以形象的用StarUml作为指引.
第二次作业
添加了状态图和顺序图的元素. 本质上和上一次作业没有区别,
第三次作业
需要进行UMl有效性的检查.
有效性检查规则很多, 这次作业涉及了8条, 其中值得注意的点列举如下:
- (UML002-R001)属性与关联对端重名的检查, 名字为null时需要直接跳过, 自关联时对端包含两个End.
- (UML008-R002)寻找循环继承, 我思路开始有些死板, 硬是按照网上几篇博客的代码实现了返回环所包含的类的方法, 后面看见讨论区里面所说的\(O(n^2)\)的思路, 为了保险我也改成了对所有点dfs一遍的做法.
- 重复继承与重复实现的检测要求, 只要对每个点进行着色即可实现.
三次作业里面, 从第二次开始遇到一个问题, 一个文件的大小超过500行... 我自认为这次的设计应该没有太大的问题, 所以解决办法是建立了几个只包含静态方法的类对一些实现进行包装.
三次作业中, 第一次强侧, 由于没有在dfs时进行标记, 导致超时一个点. 第二次作业的强侧有一个点访问到了空指针, 是我的疏忽, 第三次作业没事.
具体的IDEA生成的类图如下. 这次作业结构很简单, 完全的增量设计开发.
架构设计以及OO理解的演进
容我分说.
第一单元是表达式的求导计算, 这一单元的三次作业我次次重构, 不是因为我前一次的设计不尽人意而导致了重构, 而是我不想让代码包含丑陋的一面. 这一单元是我初次直面OO, 虽然以前在做java大作业时, 我读到了很多设计完备的代码, 但想自己写出来是另一回事. 这三次作业我按照需求, 总是先画一个晚上及其不标准的UML图来沥青我的思路, 第二天再进行编写. 方法的包装, 类的拆分的合理时机, 简单OO原则的实现, 经典的设计模式等, 都是在这个单元所经历的.
第二单元涉及多线程, 其实这一单元想要实现全部三次作业的功能, 很原始的client-worker模式就能解决一切, 电梯的调度算法基本上就算忽略, 也能拿到很多性能上的分数. 这一单元我看了各种涉及多线程的设计模式, 图解多线程设计模式这本书基本上过了一半, 但最后并没有找到我希望的设计模式, 只能依靠自己的理解进行摸索. 我在这个时候了解到, 设计模式是经验之谈, 它带给我的是更便利的交流, 以及更少的错误, 在没有思路时, 寻找前人总结的设计模式并思考延伸, 或许能获得答案.
第三单元是在学习测试?
第四单元很简单, StarUMl已经给出了架构, 就待我们去实现一些方法.
代码不是发动机, 代码可以无限壮大, 发动机长大一点就会出现故障. 但如何组织庞大的代码, 并且像擦拭发动机一般维护代码, 是不小的挑战, 是OO的职责.
OO的思想不能被语言所束缚, 这种思想所希望的结果是: 易于扩展与维护, 不差的性能, 设计与实现分离, 抽象的类之间良好的交互性等等. 这几点OO所希望的, 正是OS课程中一直强调的, 这几点说明了虚拟文件系统诞生, 外设相关软件层层递进, 内存管理, 进程管理的包装等操作的意义. OS课程中我印象最深的就是老师一直强调的"机制与策略分离". 这些都是OO的意义的良好体现, 这也说明了OO不限于语言, OO限于我的想法. 对OO的需求是自然的, 而不是人为的, 软件稍微庞大一点, 面向对象的思想必不可少.
测试的理解与实践的演进
在第一单元, 我对测试的理解, 就是拿python生成一堆数据, 再自己早一些极端数据, 用python的计算库算出结果, 进行测试, 检查结果对错, 完全自动化进行, 很轻松, 找别人的代码的bug也很有效.
第二单元, 我发现数据容易生成, 也可以添加一个线程做到评测机那样的卡点输入数据, 但是难以评判结果的对错, 因此我只能提取输出的一些特征, 进行部分的正确性判断. 其实这一单元主要在判断死锁是否会发生, 以及发生死锁后如何寻找原因, 幸运的是有一些适用于java的软件可以做到, 这里不再细说.
第三单元JUnit出场了, 单元测试对架构的解耦性要求更高, 有时甚至需要mock一些对象以方便测试, 测试粒度细了很多, JUnit的有效性显著, 还可以查看覆盖率, 唯一涉及到的问题是, 应该在编码前写单元测试还是编码后? 当然这单元十分适合对拍, 找同学要一份class文件, 写一个小程序即可.
第四单元, 我认为最有效的策略是手动测试, 这里的测试一方面检查程序bug, 一方面加深对UML规则的理解.
为了周三的演讲, 我看了一些TDD的内容, 了解到了行业里面QA, QC的存在, 意识到测试在软件开发过程中是如此重要的一环, 也吃到了一些瓜...
课程收获
其实我的收获从前几节的描述中已经显而易见, 这里只是笼统的总结.
我人为我入门了多线程设计, 入门了java, 入门了面向对象的思想.
第一单元把我从面向过程的思维中拉出来, 学习到了OO的基本特性, 接触到了OO的基本思想.
第二单元的多线程意义非凡, 多线程的设计具有一定难度, 其各种同步方法配合OS的内容, 收货很多.
第三单元, 规格化程序设计, JML建模语言, 体感: 作为理想化的系统, 不是很切合实际. 而且可靠性要求高的领域并不是JML的受众. 或者说这些领域不会涉及到java. JML对于IT可行吗...
第四单元, 学习到了UML建模语言, 了解到了很多普通的UML学习不会涉及到的点.
课程建议
下面是完全依据个人体感所提出的建议, 如有不认同可请忽略.
- 所有单元都出现的一个问题, 理论课上讲得内容, 没有足够的实践无法理解, 就像OS理论课, 很多内容没有写代码根本无法体会. 在听课时, 我经常出现"这啥?"的想法. 建议实验可以提前理论课布置. 先做两天再上课.
- UML或许可以整理精简一个文档发给大家.
- 第三单元, 或许可以砍掉, 另开一个专注于验证的选修课程, 不局限于java? 不然这种半瓶水, 助教老师出题很辛苦, 做题也很难受.
线上学习体会
OO线上学习几乎没有受到影响, 我更喜欢在家自学为主的节奏. 课堂的讨论利用微信群, 不但记录了发言, 还有序组织了发言顺序, 我觉得挺好. 就是容易忘记签到...
感谢助教老师们一学期的付出, 我受益匪浅. 这里由衷感谢 \(_ _)/