其他分享
首页 > 其他分享> > OO第四单元总结

OO第四单元总结

作者:互联网

OO第四单元总结

一、本单元作业的架构设计

就个人感受而言,本单元是对整个面向对象课程的一次总体的训练,无论是层次化设计,还是封装、继承、多态的考察,都能在这单元的作业中得到体现,算是对之前所学的灵活运用吧。

首先在不同图模型的管理上,采用了管理者的设计,通过不同的Manager对不同的图模型进行管理,如MyClassManagerMySequenceManagerMyStateManager避免了同一个类代码行数爆炸的问题,且可拓展性较好,可以继续增加图模型的种类。

而在对不同图模型的管理中,采取的是层次化的实现方法。

image

例如对于状态图的管理,在MyStateManager中,可存储不同的StateMachine,而在StateMachine中存储其唯一的Region,在Region中,又通过组合的方式存储StateTransition,其中State利用继承实现归一化存储,而transition中又包含触发事件,通过这种层次化的、树状的管理模式,能够很清晰的构建起UML的管理架构,即使再增加要求也能继续拓展。

补充一个小故事,第一次作业开始的时候,从学长的博客看到的Manager架构,以为一个Manager可以全部搞定,像ClassAttributeParameter都存在一个Manager类里面,完全按照指导书的功能要如何实现而增加各种各样的容器,没有任何层次化的管理,而且还煞有其事的画了类图,想了每个函数应该怎么写才动的手,到最后越写越乱,直接导致重构。这个小波折才让我真正意识到了老师上课所说的make sense的重要性,如果就按正文中所说,按图结构原本的层次进行管理,各种操作都方便得多,好的架构一定是符合现实的情况的一种抽象,这也是马克思主义中对真理的定义。

由于此次作业中顺序图类图两者之间存在交互关系,而且主要是类图中的类的id需要被顺序图所引用,因此单独设计了一个Classes类对类图中所有类与接口进行存储,并设计方法既可以通过id访问类,又可以通过name访问类,进而使用单例模式,使得Classes可以在两种图模型之间进行交互,比较优雅的解决相互联系的问题。

另外由于各个Manager进行初始化时需要对元素类型进行特判,为了进行统一管理,专门设计了TypeJudge类,负责所有对instance of统一管理,向外提供接口,实现比较优雅的封装。

二、四个单元中的架构设计

第一单元

第一单元架构是老师的推荐架构,现在看来也是比较合理的架构,将原子变量、复杂函数、运算符都抽象出共性——作为一个项,并可以求导。因此对于这些不同的项,均可继承自同一个类,并通过这个公共的父类实现求导的接口,使得在主函数中可以统一化的存储、调用、管理,实现继承上的层次化设计。这种依赖倒置的原则是我第一单元的深刻体会,也是我目前所认为了面向对象的本质特征之一,这种思想方法无论是对于对象的抽象拆分还是层次化的安排都有着很强的指导作用。

这样的架构其实也不算特别难想、难实现,真正的问题在于怎么把输入转化为这些规整的类。这对于当时的我来说确实是一种挑战。递归下降也好、表达式树解析也好,由于没有好的方法和思路,实现起来都很慢,而且错误百出,缝缝补补,最终来看虽然功能实现了,但可读性和拓展性都很差;而且由于精力所限,最终一点优化也没做,还是很遗憾的。

第二单元

第二单元涉及多线程,线程之间的同步和互斥是一个难点,为了使线程安全的问题尽可能的少,采用的架构是两对简单的生产者消费者模型,调度器负责把各处的请求(主要是输入线程)分派到各个电梯的请求队列当中,电梯配置一个控制器,根据电梯的请求队列控制电梯的运动。这个架构是比较好写的,也能适应各种各样的情况,诸如换乘、更改电梯的运行策略等,拓展性也比较强。

这个单元的架构意识算是比较强了,后两次作业都是把类图画好再开始写代码,写的过程中也还比较顺利,但由于很多细节没注意到,导致暴雷,也真的感到遗憾,过于从宏观的角度理解作业的目的,结果反而在细节上出了问题,还是没能把握好关键问题所在。

第三单元

第三单元就不太能谈得上架构设计了,毕竟总体架构官方包都已经给出了,只是实现一些接口就行。这一单元的核心问题其实在于设计与实现相分离,而这一问题其实是软件开发都需要注意的。

第四单元

第四单元其实算是两部分,一部分是对UML图的理解,而UML图是很面向对象的,它的层次化管理的方法值得学习,而另一部分就是我们的作业,对UML图进行解析,由于UML图是很面向对象的,则解析与查询也应该按照UML图原本的样子来安排,这就有了第四单元层次化管理的架构,也有了对于make sense的深入理解。感觉这一单元像是第一单元和第三单元的综合,既有层次化的设计,又有对每个方法的具体的要求。

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

第一单元、第二单元对于测试都没什么概念...第一单元在输入处理上纠结的时间太久,连优化的时间都没有,更不用说做测试了;第二单元是觉得自己的架构搭的比较好,对自己的代码有信心,也就没有了做测试的欲望,于是也就彻底崩了。

经过了前两个单元的毒打,终于明白了测试的重要性,于是在任务量比较小的第三单元,真正开始写起了自己的评测机,生成随机数据,并和他人进行对拍,也测出了不少的错误,再一次加深了对测试的理解。同时在这个过程中也熟悉了jar包、命令行、脚本文件、python这些常用的工具(虽然掌握的还是比较浅)。

到了第四单元,想要生成随机数据还是有一定难度的,因而这个单元主要采用的是手造数据,对各种情况进行枚举的测试方法,然后再与其他同学进行对拍,到了这个单元测试就比较熟练了,自己写的脚本能比较轻松的一键实现自动化对拍测试,相比起第四单元刚开始要一个数据一个数据的解析,还是进步了不少。

当然自身对于测试还是做的很不够,相较于其他同学而言,感觉自己才刚刚入门,如何在python程序里引用jar包,实现命令行的代码等等,还是需要自己不断学习的。

四、课程收获

花了很多时间,但也学得并不很理想,不过也算有所收获吧。首先是对于Java的掌握的提升,这是毋庸置疑的。从个人角度来说,我还是挺喜欢面向对象这种编程思维的,而Java恰恰以其特有的机制承载其了这种思维,能够很方便的将这种思维落实到实践中。这是从比较高的角度看待这个问题。具体的收获,放到每个单元来说会更加清晰一些。

第一单元

第二单元

第三单元

第四单元

五、给课程的建议

关于其他

说起来,还是应该直面自己的失败。一个盲目的,没有任何方法、没有任何方向的学习过程,最终是会撞得头破血流的。反思自己第一、二单元学OO的心态,的确存在着很严重的问题,所谓不卷,就是完全放弃对自己的要求,不但第一单元的化简完全放弃,自己从不构造数据进行测试,甚至连之前强测中给的数据也不测,懈怠到如此地步,实在是令人匪夷所思。

不过也好,失败令人清醒,教训既然已如此惨痛,就使人认真总结,好好吸收。都说资本主义社会的经济运行有周期,感觉自己的运行也有周期,而且两种感觉极为相似,都是到了某个临界点时产生了泡沫,于是开始破灭。而说,资本主义是有其根本矛盾的,正是因为这个根本矛盾导致了经济危机的产生,所以要从根本上解决经济危机,就必然要解决资本主义的根本矛盾,所以也可以类比,这样的规律作用在自身身上,就要解决自身的根本矛盾。那么根本矛盾是什么呢?仔细想想,矛盾是很多的,但哪一个是根本,或许还得细细斟酌,那么就先把握住这个核心的问题吧。这里就提出一点,就是自己在专业上封闭的心态,这是高中的时候形成的,是为了保护自己脆弱的自尊,但高中所学、身边的人,大体都类似,倒也感觉上利大于害了,但发展到现在,到了大学,还如此封闭,连这种表面上的利大于害都不复存在了。高中的实践形成了这样的认识,但由于矛盾的变化,实践条件的变化,这样的认识反过来对现在的实践起阻碍作用,那么,就应该调整、改变这种认识,而认识从实践中来,所以需要做些更开放的事情,形成更全面、更充分的认识。

“过去的生命已经死亡,我对于这死亡有大欢喜,因为我借此知道它曾经存活”,OO的课程也就这样结束了,但无论是在理论课、研讨课上,还是在平时和同学的讨论中,都迸发出了很多思想的火花,也沉淀下来了一些东西,也算”借此知道它曾经存活吧“,不过的确应该调整状态,才能迎接的了更多更大的挑战了。

标签:OO,层次化,架构,实现,作业,线程,第四,单元
来源: https://www.cnblogs.com/Aressfull-blog/p/14934346.html