凡此过往，皆为序章。
不知不觉OO课程即将落下帷幕，一路坎坎坷坷磕磕绊绊，可算是要结束了，心里终于松了一口气，也有小小的不甘和遗憾。凡此过往，皆为序章。特殊的线上OO课程结束了，但面向对象的旅程才刚刚开始！
一、第四单元架构设计
-
第一次作业
本次作业是完成类图的解析器,对类图进行一些基本的分析,如对类图中类操作属性关联实现继承等查询.
我认为第四单元作业第一步要解决的是对UML的几种主要视图,特别是类图,状态图,顺序图的结构和mdj文件结构的分析.如果将UML图的结构和mdj文件的结构分析得当的话,这一单元作业就好上手了;否则就很难搞清楚这一单元在做啥.
在做第一次作业之前我花了大量时间在查找UML相关的各种资料，才发现了上面这一点，其实从作业的角度来说，最有用的资料就是ｐｐｔ和ｍｄｊ文件了．
以下是我在解析类图时画的思维导图：（有些粗糙，但表达ｍｄｊ文件下类图的主要结构已经够了）
当时照着类图我就直接下笔了,脑子里第一个想到的就是各种HashMap管理的UmlElement,精心设计HashMap的<key,value>就可以很方便的查找想要的数据.当时我也想过,借鉴第三单元,封装类建树或者建图,但立马给否决了,因为我觉得建树或建图比较麻烦,需要重新封装类,将各个数据送入相应的位置,查找也没有一万个HashMap来的方便.
所以我的架构就是一万个HashMap,将所有UmlElement用hashMap保存起来,直接查找,操作简单.
像这样:
这种做法,优点在于简单粗暴,构造时简单粗暴,查找也简单粗暴,"扁平化"管理数据写起来很爽.
缺点也在于简单粗暴,除了管理数据时运用了hashMap,在其他方面完全没有体现java的面向对象思想,写完之后才发现完全是面向过程,极其容易造成一个类超超重! 文件过长!我写了足足600+,checkStyle完全没法过!真不知道我当时脑子是怎么了,学了一学期面向对象的思想都忘了.另外,还有一个致命的缺点是测试和拓展起来非常麻烦,由于一直都是面向过程式的代码,纠结于各种细节,容易出错,也比较难定位错误.这在我测试的时候深深体会到了!
但幸好,当时思路清晰,课下测试之后,课上没有再发现bug.
-
第二次作业
第二次作业迎来了我第一次无效作业,痛心!
为什么呢,遭报应了.众所周知,我是一个压ddl的大师,这学期在家学习见不到可爱的小哥哥小姐姐,没有了外界的刺激,学习的积极性有段时间下降了很多,逐渐地就养成了压ddl的坏习惯,无论是OS实验还是报告还是OO作业还是博客还是bug修复还是各种带截止日期的事情，我在学期的后半段都把它看成了(大概是)上级交给我的"任务"做完如释重负的感觉多于成就感......无论多大点事儿我都能给自己兴风作浪最后大概率成功渡劫有惊无险.就这样我过上了和ddl对线的生活.
严肃地说,这样压ddl是非常危险的,也是对自己不负责非常错误的行为,你看我这次就遭报应了不是.常在河边走,哪有不湿鞋. 第十五周的周四是OS的考试,OO课程组非常贴心地为我们把ddl延后了两天,我以为延后到了周二,其实是周一.为什么我会这样想呢?因为我懒到一个星期连网站上的通知都不看,我是在群里看到有人说周二截止的.于是,我这次本来给自己周一和周二两天的时间完成这次作业(这样干很危险,但我已经不是第一次这么干了,这都怪我).在周一晚上八点的时候我还在构思,无意中点进网站上看到了截止日期,我 人 都 傻 了.
这个时候我连笔都没下,还剩一个多小时.我方才如梦初醒,痛心疾首,心里除了难受就是难受.没想到我第一次无效作业就提前预定了.我还说打算一雪前耻?这次作业无效了我要进补给站了?我不会这次扣个十几二十分吧? ......
下图是我后来特意截了屏,留给自己做个警示,长长教训.
(我也不怕丢人,全是我自己的错.反正不会有人看我博客,就把这段"难忘的故事"留在博客里了和助教们分享了)
以后没有特殊情况,再也不压ddl了!!!意识到有该完成的事情就立马去做!
今日事今日毕!(这么简单的道理为啥我现在才懂???)希望自己可以做到,不想再体会和ddl中门对狙,最后我被反杀的生活了!
好言归正传,之后我又多出了一个星期的时间:) ,于是我仔细分析了之前的不足,设计了另一种"更加面向对象式"且能说服的架构:
本单元实际上就是给一堆数据,让我们进行有效的层出化的组织管理,统计数据的特征等等.
我们的解析器必须解析UML类图,顺序图,状态图,那么其实可以针对本次作业的目的,在UMLElement的基础上进一步抽象,将紧密相关的数据集中起来管理,这里我们可以借鉴上图所示的类图思维导图(图中没画出顺序图和状态图,但同理不难画出)以及mdj文件结构.这就需要封装类等操作,管理相应的数据.
这里我拿UMLClass和UMLInterface举例,
当时我设计了MyCLassifier,用来存放类和接口以及相关的UMLElement,其实如果把UMlElement看成结点的话,这就形成了一个树结构.
那么关系(关联泛化实现)该怎么管理呢?也放进MyClassifier里吗?还是直接放在MyGerneralInteraction中呢?这里由于关系涉及两个MyClassifier,我就建了一个RelationManager接口,设计了GenManagerAssoManagerImpManager来管理泛化关联实现关系,并和MyClassifier进行了关联,方便处理与泛化关联实现相关的指令.
对于后来顺序图状态图,可以以相同的思路进行模块化设计.
UML类图如下（隐藏了依赖关系）：
-
第三次作业
模型有效性检查.
由于是最后一次拓展,这一部分我比较匆忙,将模型有效性检查任务细分分派给了不同的类.暂时没有想到有什么更好的架构设计.
但是由于之前进行了重构,在架构设计合理的情况下有效性检查不难,这次作业我只花了一天的时间就完成了.
经过对前两次作业的充分的课下测试,这次作业强测没有测出bug,算是"有始有终"了吧.
二、架构设计与OO方法理解
-
层次化设计
这一单元的主题是层次化设计,
主要的设计思想就是利用面向对象的设计思想,将问题抽象成对象和类,围绕数据进行层次化和模块化的设计,这一方面的训练对于接下来的单元都很有必要且很有用.
主要就是抽象出多项式因子表达式因子三角函数......加减乘除求导操作等等,然后进行层次化和模块化的设计.......
具体架构设计见第一单元博客
-
多线程设计
这一单元的主题是对象的运行时行为状态与并发控制, 这一单元首次接触了一个十分重要的概念－－并发设计，算一次用java语言的多线程编程入门.
主要就是理解多线程并发时对象的运行机制,对并发行为进行基本的分析,对线程安全并发行为设计有一定的理解,就能完成这单元的作业.
当然我更了解,多线程编程还有很多值得探索的地方,如如何保证线程安全,在尽可能保持高并发的情况下保证软件的正确性和正常功能.
具体架构设计见第二单元博客;
-
规格化设计
这一单元的主题是(基于JML的)规格化的面向对象设计,我们接触了契约式设计思想,只需要根据规格实现接口,对规格的理解是一方面,另一方面是在功能正常的情况下对性能的追求.
另外,这一单元引入的重要OO方法有Junit单元测试,除了传统的黑盒测试之外,还有Junit单元测试,能够对一些方法进行回归自动测试.
其实我认为这一单元难点在于如果按照规格实现高性能的程序,
换言之,图的算法和数据结构;具体架构设计见第三单元博客;
-
模型化设计
第四单元的主题是模型化设计,学习了UML语言的基本用法和语言结构，UML模型入门与解析＼UML模型验证等等，
具体分析见上文.
三、测试与实践
我知道课程组预期的测试与实践板块下的内容是什么:
理想中的我的演进:
远古时代:严重依靠评测机,评测机=测试;
石器时代:
手动测试,想到什么测什么,测出bug全凭运气和心情;
青铜器时代:
学会用python和大佬在线对拍,大佬正确我就正确;
蒸汽时代:
学会用python和第三方库自己搭建小的评测机了,利用脚本测试SoEasy!
电气时代:
不仅会python写评测机,还会Junit全方面测试,测试无死角,黑盒白盒一起上!
.......
但实际上,本蒟蒻的演进历程:
现实中我的演进:
远古时代:严重依靠评测机,评测机=测试;
石器时代:
手动测试,想到什么测什么,测出bug全凭运气和心情;
手动测试,学会根据架构和具体的问题等设计一些数据保证尽可能多地覆盖和考虑极端情况/边界条件;(这算是真正进步了)
学会让大佬慷慨解囊,帮我对拍,大佬正确我正确;
学会让大佬慷慨解囊,帮我测测,大佬利用脚本测试SoEasy!
学会基本的Junit测试,这算是学会了吧,但我觉得Junit测试很鸡肋,不是所有方法都能测试,很多复杂方法或者只改变状态不返回值的方法就测不了,或者说很麻烦,另外,就算测试了也不能保证整体正确,只能辅助.关键是非常耗时,适合增量式开发,后期加测试数据好加......
我对不起课程组,对不起助教
不会的原因: 大概是,我不会用python写脚本,写评测机,是因为我对python语言不熟悉,我寒假学习了py,但时间都用在了学习py语法上,虽然这对我迅速掌握java语法有帮助,你们可能不理解,但确实我还是无法自己在没有指导书的情况下自己创造一个玩具程序解决实际问题,我可能目前只会做题吧......
当然这问题很严重,测试是OO的关键一环,遥想OO旅程,很多次的熬夜都是在debug,有很多点挂掉都是因为测试不够充分而非架构设计问题审题.谁能保证程序员编写代码一次就过呢,测试是真的很重要,编写脚本算是程序员的必备技能(对不起我现在还不配当程序员,OO课程结束了,只能暑假努努力了!希望助教给点学习py的建议！
四、课程收获与体会
面向对象设计与构造(OO)这门课程设计得很好,目标是通过层次化设计多线程设计规格化设计模型化设计让同学们较为深入地理解面向对象的设计思想,并通过 实验和研讨课的方式保证同学们的学习进度,促进同学之间的技术交流.实际上课程的效果我认为大部分都达到了,在我眼里这是一门硬核的设置合理的专业课,只要同学们认真学习,一定都能有所收获,有所长进!在我之前的认知里,这门课比较魔鬼,还会造成人际关系的破裂,可怕,但由于老师和助教的精心打磨,今年呈现的效果应该是很好的了,给个好评!老师和助教们都辛苦了!
具体的话,我在这门课里学会了较为熟练使用java,深入了解了面向对象的基本思想,多线程入门,测试方面也有所反思,架构设计也比之前进步了不少.如果说和学完数据结构来比较的话,肯定是学到了不少!当然我认为OO课只是开始,还有很多java的高级应用很多软件设计的思想等等值得我们学习.这都是需要我们自己学习探索的!
线上OO课的体会:
疫情期间不得不线上学习,见不到可可爱爱的同学,我的学习效率大打折扣,学习热情也比上学期减少了不少.其实客观来说这学期的课业不重,OO课也真的是只有第一单元和第二单元吓人而已,后面两个单元都是第一次作业唬人. 这学期只需要面对OO和OS两门专业课,一般专业课都取消了,只是由于我自己的原因(如拖延.压ddl,消极学习,不自律等等,疫情有段时间我真的自闭;还有长期以来的生活习惯生活态度不"健康",学习态度扭曲了一些balabala)导致我有段时间忙得忙死,闲得闲死......这学期的OO旅程一路坎坷,前两个单元做的还可以,最后两个单元却磕磕绊绊,实在是遗憾!但凡此过往,皆为序章,希望我能认真反思自己,从暑假开始,尽力而为,做更好的自己,不再后悔哦!
五、建议
-
希望无效作业之后仍然能够参与bug修复,即便bug修复之后这次作业也不得分.
倒数第二次作业无效之后,我重构了,也就是说,我一个星期不得不写三次作业的量,这工作量不小.当我想要测试第二次作业是否正确时,发现bug'修复无法参加.我认为这对那些无效作业的同学造成了不小的挑战.相当于这次无效作业了,需要一次至少写两次作业,增加了下一次作业出bug甚至无效的风险.
希望无效作业之后仍然能够参与bug修复,这样对无效作业的同学更加友好,避免出现本单元后续作业均无效的情况.
-
课堂讨论问题建议直接点名或者强制发言,讨论区发言次数设下限,从而促进同学们踊跃发言和促进技术交流;而研讨课建议增加筛选力度,防止有人水研讨课得分.
关于讨论区,字面意思,设定最少发言次数;
关于研讨课,希望增加审核力度,我发现后期有很多同学划水,分享的ppt内容质量并不高而且ppt很短感觉并没有准备充分.另外如果有重复的话就不要再分享了.因为听了一堂课感觉其实没分享什么干货其实很扫兴的也对那些认真准备的同学不公平(
有些水研讨课的感觉我上去讲也能讲出来貌似没有多少值得分享的内容)如果研讨课参与的人数不多,可以提前拟一两个主题,启发同学们去准备. -
emmm,不是说有业界大佬回来分享吗,为啥等到最后也没等到,业界大佬给咕咕咕了嘛?
- 开放实验结果或答案，好知道是对是错，也对学习状态做个反馈和审视。如果能开辟个时间讨论实验就更好了。（或许可以放在老师实验讲解的视频。也可以放在研讨课）
最后的最后，感谢在OO旅程中不厌其烦帮助过我的老师、同学、助教们，你们真的帮助我很多，给我很多收获。
凡是过去，皆为序章！To be a better man!