精华内容
下载资源
问答
  • OO第四单元

    2019-06-23 23:11:00
    OO第四单元总结 第四单元架构设计 第一次作业 uml类图 这次作业我采取的基本思路就是根据指令来建造一个简易的类图,用于查询,其中umlclass中包含了umlAttraibute,umlOperation等.整个架构分为四层,首先是main函数,...

    OO第四单元总结

    第四单元架构设计

    第一次作业

    uml类图

    1615478-20190623231033788-929657260.png

    • 这次作业我采取的基本思路就是根据指令来建造一个简易的类图,用于查询,其中umlclass中包含了umlAttraibute,umlOperation等.整个架构分为四层,首先是main函数,然后是交互类intreation,交互类每获得一个元素,就将其送入ananlyze进行分析,analyze通过分析来将其添加到适合的位置以建造类图.最终当所有的元素都被分析完了,我们就得到了一个简易的类图,接下来交互类中的各种查询就非常简单了,仅仅就是查询类图的相关信息即可,而不是面对极其抽象的语言.但是使用此架构一定要注意分析元素的顺序,再分析元素之前要保证顺序合适以避免类的属性在类被建好之前就被分析,从而添加不到合适的位置.

    第二次作业

    uml类图
    1615478-20190623231048679-1298261694.png

    (由于这次作业的类非常多,所以uml类图只截取了部分,总代码约2200行.....)

    • 这次的架构相对于上次来说基本上没有太大的变化,还是分为交互层,分析层,和基础层,交互层获取元素并送入分析层进行分析,分析层分析元素并使用基础层的类构建类图,最终由交互层对建好的类图进行进行查询操作,对比于上次,仅仅是在基础层增加了一些新的元素,在分析层增加了分析类,在交互层设置了顶层交互和三个不同类型的(类图,状态图,顺序图)的交互类.第二次沿用了第一次的代码,对原来的代码几乎没有改动,也没改变架构,仅仅是增加了一些种类.

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

    第一单元

    • 第一单元基本上谈不上什么架构设计,甚至是连基本的面向对象的思想还不是很适应,还是用的老一套的面向过程式的写程序,几乎所有的代码都集中在一个类中,就是main类,导致这个类非常臃肿,基本就是为了完成任务而应付着写的,也谈不上会考虑迭代方面的问题,第一次的作业代码,基本上第二次就用不上,所以几乎是次次重构,类的数目虽然每次作业也有所提升但基本是为了应付,是为了分类而分类,多个类在当时使用时也非常的别扭,还是在想为什么不把所有东西放入一个类中,这样写着也方便.

    第二单元

    • 第二单元是多线程,这一单元的最大收获也是多线程,并发的理解,一千从未接触过,甚至是根本无法想象多线程并发的程序是怎么写的,经过这个单元,从最初的只会一条道路看问题到学会用并发的角度来看待问题.当然,除此之外,就是对面向对象的概念总算有了初步的适应,已经开始习惯着用面向对象的方式来思考问题,写代码了.至于说架构方面,就是开始以类为单位来思考架构了,以及以多线程资源共享的架构来思考问题,还知道了设计模式的概念,整个单元运用了单例模式,观察者模式,还有生产者-消费者模型等等.

    第三单元

    • 第三单元是JML,通过这一单元知道了规格化的方法,也初步体会到了规格的威力,自然语言的二义性真的是一个硬伤,我个人也有很多关于理解错题意而导致出错的不好的回忆.使用规格化语言就可以避免自然语言的二义性问题,这无疑是极好的,有了规格,无论是写代码也好,测试也好都会变得非常的方便.但是硬伤是规格写起来真的是非常麻烦,简单的方法,本身实现就很简单再去专门去写规格就会显得非常的不值,而复杂的方法写起规格就会极其复杂,首先要确保你的规格是绝对正确的,这一点就已经非常困难了,其次,写出来的规格又极其抽象复杂,读起来非常不友好.所以这样下来,规格化语言的地位就会显得非常尴尬了.至于这一单元的架构设计,我首先要吐槽一句了,说好的最难的都在前两单元,最后两单元非常简单呢?,尤其是第三单元的第三次作业,我个人认为可谓是整个OO的难度巅峰了,在这次作业里,你要有扎实的数据结构知识,你需要有一个性能良好的算法来保证你的程序不会超时,而由于这次代码量也很大,所以还要有一个清晰的架构.当然,与之相对的,对算法,架构,基础知识等都是一个很大的考验,做完之后提升也不小,对OO又有了更深一层的理解.

    第四单元

    • 第四单元是UML,UML比起JML就显得非常直观,通俗易懂了.在真正下手之前,有一个UML图还是非常不错的,对自己来说,先构造一个清晰易懂的图形会使得接下来写代码的过程中不会迷茫和混乱.我以为这一单元会是让大家真正动手画UML图,还在考虑该怎么评判,结果作业竟然是一个UML分析器.当然,这次的收获也非常多,主要是学会了对代码进行层次化封装,我这次作业就将其分为了交互层,分析层,和基础层三层,然后接下来的代码之路就异常清晰和简易,所以可以看到一个良好的架构对编程效率是多么的重要

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

    第一单元

    • 第一单元的测试方法非常简单,就是人肉测试,自己会想一些边界数据,或者特殊值等,以及自己在写代码的过程中写出的bug所对应的测试数据,然后是一些随便编的数据.

    第二单元

    • 第二单元是多线程,多线程测试起来非常复杂,主要是因为很多的bug都不能复现,而直接使用idea的单步运行在多线程里就几乎无用了,最原始的测试方法就是printf这样其实测试起来效果还不错,但是和其他同学交流后知道直接输出的话是有一些问题在里面的,之后在课上又听说了断言测试,以及可以使用log的方式进行测试.

    第三单元

    • 第三单元是JML,既然是JML当然是使用JML独有的自动化测试咯,但是,老实说,测试用的那几个软件安装起来非常复杂和繁琐,废了很大功夫安装好后发现所谓的自动化测试的效果却非常不仅人意,测试的事件消耗非常长,却仅仅是测试了它所谓的边界数据(其实一点也不边界),导致真正的bug并没有被测出来,所以对我个人来讲就全当摆设了.这一单元的最大收获还是Junit,Junit的体验就非常好了,测试起来非常舒服和方便,简直是为我的测试手段打开了一个新世界一般.

    第四单元

    • 老实说,这一单元在测试手段上并没有什么突飞猛进,而由于源文件是个图,我也没办法进行自动化测试,不过倒是对以前掌握的一些测试方法进行了巩固.

    课程收获

    • 通过这门课,我从一个只会写C代码,毫无架构,随心命名,面向过程的小白初步成长了很多,对代码规范,代码架构,代码测试等都有了非常大的提高.尤其是掌握了面向对象的思维方式,使得我现在的思考问题角度有了很大的扩展,在以前写一个一二百行的代码都痛苦无比,整个代码一团乱麻,抽象难懂.现在最后竟然写了一个两千多行的代码还能保有一个清晰的架构.感觉我也没有经历过什么算法上的提升,也没有经过真正意义上的代码的大量训练,而能够提上如此之多,关键是思想上和以前完全不一样了.

    建议

    • JML这一单元的体验真的非常不好,非但没有让人想去使用它,反而对其更加反感
    • 一个小bug可能导致强测全面崩塌,导致最终付出和汇报的比例严重失衡,所以建议强测也可以修复
    • 说好的后两个单元简单,结果第三单元第三次作业难度直接在所有作业上提升了一个量级,第四单元则直接让我写出了2200行的历史新高.

    转载于:https://www.cnblogs.com/miokun/p/11074842.html

    展开全文
  • OO第四单元总结

    2019-09-24 21:46:55
    目录 OO第四单元总结 一、本单元架构设计 1、第一次作业 2、第二次作业 二、架构总结 第一单元 第二单元 第三单元 三、测试与实践总结 第一单元 ...

    OO第四单元总结

    一、本单元架构设计

    1、第一次作业

    ​ 建立了四个功能类来完成各部分查询功能,降低耦合:

    AssociationManager类用以管理UML类的关联

    AttributeManager类用以管理UML类的属性

    OperationManager类用以管理UML类的操作

    InterfaceManager类用以管理UML类实现的接口

    ​ 在MyUmlClass中,实例化了上述四个类,添加方法与查询方法分别调用对应Manager中的查询方法。

    ​ 建立了MyUmlInterface类,在UmlInterface的基础上,封装了父类接口的添加以及查询所有的已继承的接口的功能。

    ​ 在MyUmlInteraction中,根据Umlelement建立对应的对象,查询时对应查询即可。

    ​ 类图如图所示:
    1615442-20190621222814068-968016249.png

    2、第二次作业

    ​ 在第一次作业的基础上:

    ​ 顺序图:

    ​ MyInteraction封装顺序图,内部存储lifeline、message等信息,用以管理顺序图相关的查询。

    ​ 状态图:

    ​ MyUmlstate在Umlstate的基础上,存储了直接后继状态的信息,可以查询后继状态的个数。

    ​ MyUmlRegion管理下属的所有state,并提供对应查询方法。

    ​ MyUmlStateMachine实例化并管理UmlRegion,在本次作业中,由于只有一层UmlRegion,嵌套关系可以省略,但是分层管理的思想还是很重要的。

    ​ 类图如下所示:

    1615442-20190621222831370-2099871986.png

    二、架构总结

    第一单元

    ​ 由于当时还不是很会使用接口,采用了几乎三元组的方式管理多项式,导致程序不仅耦合度高,而且可扩展性极差。

    ​ 更类似于面向过程的思维方式,导致类的抽象层次无法很好的把握。抽象层次越高,码量会越大,维护起来也更为复杂,在抽象与下次作业的扩展无关时,只能徒增工作量。而抽象层次过低,则会导致代码耦合度过高,甚至于出现完全面向过程、一main到底的情况。如何平衡抽象层次与架构的关系,是当时困惑我的一个主要问题。

    ​ 第一单元第二次作业中,我把变量抽象成了一个类,在第三次作业的需求中,这个抽象当然是毫无意义的,保留只会增加码量。于是在重构的过程中,我就删除了这一级的抽象。

    可见,抽象层次还是与具体需求密切相关的。改需求真的是一生之敌。

    ​ 附上当时的类图。
    1615442-20190621222901996-1945878407.png

    第二单元

    ​ 多线程电梯问题中,我对架构的重要性有了一定的了解,对于多线程可能存在的并发问题及相应的解决措施,也算一知半解。在架构的过程中,我把调度器与电梯的职能划分清楚:调度器负责接收与分配请求,电梯负责按照一定的逻辑/算法,运送人员。这样一来,每个线程的分工就非常明确了。在第二次作业中,虽然只有一个电梯,可以采用主动从调度器拿请求的方法,但我还是采用了调度器主动分配,利于多电梯的扩展。

    ​ 不过有个比较遗憾的地方是,本单元作业存在电梯类逻辑过于复杂的问题,方法数达到了20多个,这不仅不利于维护,而且带来了很大的风险。

    第三单元

    ​ 涉及到了面向过程与面向对象思想的结合。建立Graphs类来管理图相关的算法(floyd,bfs,dfs等),以公共静态方法的形式存储。这样可以将数据结构相关的图算法与业务逻辑分离,便于管理。

    ​ 在面向对象与面向过程逻辑的结合中,对面向对象的思想的理解更加深刻了。

    三、测试与实践总结

    第一单元

    ​ python生成随机数据+sympy库对拍,依靠大数据轰炸测试。

    ​ 使用已成熟的运算库来作为正确输出对拍,只需提供随机输入便可自动测试。

    第二单元

    ​ python生成随机数据+正确性逻辑(不得超速、不得超载,必须送到指定楼层等)分析输出。

    ​ 依赖指导书所给的正确性逻辑,可以判断输出中电梯状态是否违法,依次可判断输出是否正确。

    第三单元

    ​ Junit单元测试与小范围的python随机数据对拍。

    ​ Junit测试的优点在于,白盒测试有利于定位错误,可以尽可能地覆盖代码的每一处。因此采用黑盒+白盒的测试方法,既可以用大量数据的轰炸测试寻找bug,又可以在出现bug时快速定位问题所在,不可谓不妙。

    第四单元

    ​ Junit测试与部分对拍。

    ​ 手搭数据生成器工作量太大了,考期实在没那个精力了。

    四、课程收获

    ​ 1、对面向对象的思想与架构设计有了自己的了解,包括不限于工厂模式、观察者模式等。

    ​ 2、认识到了架构优先的重要性,遇到一个问题应该首先思考如何架构,而不是直接动手写代码,后者往往会面临一次次的重构。

    ​ 3、对于代码规范的表达形式有了一定了解。

    ​ 4、初步了解了Uml类图、顺序图的层次与含义。

    ​ 5、最不重要的一点,学会了一点Java。

    五、建议

    ​ 1、在前几次作业中,引导学生完成从面向过程到面向对象思维的转变。在刚开始介绍面向对象含义的时候,大家对这个概念可能有一定自己的理解,但不是很深刻。如果这个时候有一些提示性的操作,例如建立好求导接口,要求在作业中实现等,可能会使得这个过度更加平滑一些。

    ​ 2、有时间限制的作业,提供给学生参考时间的渠道。例如在网站上提供一个窗口,可以提交代码,只返回对应的CPU时间、内存占用等信息,不返回评测信息。数据也由学生提交。这样可以使得学生对程序耗时有一个大致的估计。评测机的环境与本地相差较大,有一些同学反映本地可以立刻给出答案的点,在评测机上就TLE了。

    ​ 3、助教问题。结束的时候才知道9个助教已经确定了,本来还想申请一下助教的,没想到直接内定了。这样的事情不公开,还是觉得很奇怪。

    转载于:https://www.cnblogs.com/tqnwhz/p/11067107.html

    展开全文
  • OO第四单元博客作业

    2019-06-23 14:52:00
    OO第四单元博客作业 第四单元两次作业的架构设计 四个单元中架构设计及OO方法理解的演进 四个单元中测试理解与实践的演进 课程收获 给课程提建议 OO第四单元博客作业 第四单元两次作业的架构设计 这两...

    OO第四单元博客作业

    第四单元两次作业的架构设计

    这两次作业仍然是实现官方提供的接口,最大的收获便是通过自己写代码解析UML语言熟悉了UML语法

    第一次UML类图解析作业

    第一次作业要求我们实现一个类来完成对类图各个讯息查询的功能。

    由于输入的各个umlelement都是通过parent等讯息来储存元素之间的从属关系,而查询指令大多都是要查询某一类的相关讯息,因此我选择了自己封装一个MyUmlClass类,存储与这个类相关的讯息,包括属性、父类、关联元素、操作等,同样的,对Interface、Operation这种包含有其他元素的类也进行了封装。在构建完各个元素之间的从属关系之后,查询就简单了许多,直接枚举需要查询的元素即可。

    结构图如下:

    1615856-20190623131743435-1986527986.png

    耦合如下:

    1615856-20190623131832357-2144140473.png

    在做完第二次作业后反思,觉得自己在封装一个类的关联元素时拓展性做的不够好,应该存入associationend而不是与类关联的那个元素,因为end中也存有和这个类有关的讯息,如果直接存关联元素,提取end中的信息就需要重新遍历关联关系,而存入end,不仅可以使得信息完整,而且通过reference查询关联的元素也并不麻烦。

    第二次UML类图解析作业

    第二次作业要求我们加入对顺序图和状态图的解析,以及检查类图是否符合正确的规则。

    第一次作业相关的指令我使用继承上一次的作业解决。

    本次作业是oo的最后一次作业,考虑到进入烤漆,课程组也帮我们在数据上做了许多简化,对顺序图和状态图讯息的查询都是简单的遍历元素即可完成,考虑到没有下次作业也就偷懒没有进行什么设计直接暴力枚举了。对于类图的正确性检查,因为一开始指导书并未说明,会不会出现类多继承,接口继承类等非法情况出现在数据中,我采用了别的同学的一个很好的想法,把类和接口都一视同仁当作点,按照实现和继承关系建边,构造有向图,然后就是使用dfs来判断是否有环或重复继承。

    结构图如下:

    1615856-20190623133414637-2015178614.png

    耦合如下:

    1615856-20190623133551577-2054553217.png

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

    • OO第一单元有三次作业

      从普通的多项式求导,到带有幂函数、三角函数的表达式求导,再进化到加上嵌套函数的表达式求导。

      • 第一次:将单项式和多项式抽象成两个类
      • 第二次:多项式使用ArrayList存储单项式,单项式使用ArrayList存储因子,再额外使用Biginterger存储单项式的系数,各个因子类共同抽象出一个父类包含一个index指数属性。多项式求导调用单项式求导再相加,单项式求导调用因子求导先相乘再相加。
      • 第三次:在原有类的基础上增加了poly型因子并将三角函数因子改为嵌套型因子,还把输入和输出抽象成单独的类
    • OO第二单元共三次作业

      需要完成的任务依次为单部多线程傻瓜调度(FAFS)电梯的模拟,单部多线程可捎带调度(ALS)电梯的模拟,多部多线程智能(SS)调度电梯的模拟。

      • 第一次:使用生产者消费者模型
      • 第二次:生产者消费者模型
      • 第三次:生产者消费者模型
    • OO第三单元共三次作业,需要完成的任务大概是统计图的简单信息,图的连通及路径信息,仿地铁线的无向图带权最短路信息。
      • 第一次:只有MyPath和MyPathContainer
      • 第二次:只有MyPath和MyPathContainer
      • 第三次:只有MyPath和MyGraph
    • OO第四单元共两次作业,需要完成的任务为统计uml类图信息,统计uml顺序图、状态图信息及类图正确性检查。
      • 第一次:封装一个MyUmlClass类,存储与这个类相关的讯息,包括属性、父类、关联元素、操作等,同样的,对Interface、Operation这种包含有其他元素的类也进行了封装。
      • 第二次:把类和接口都一视同仁当作点,按照实现和继承关系建边,构造有向图,然后就是使用dfs来判断是否有环或重复继承。

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

    我的OO测试经历了手动构造数据测试,到搭建评测机测试,再到评测机junit单元测试辅助测试。

    通过惨痛的bug经历懂得了测试以及覆盖性测试的重要性,以及如何做到全面覆盖的测试,也学会了写生成数据的脚本、写spcjudge脚本、写对拍程序等

    课程收获

    一学期的OO课程,让我感觉收获颇丰,入门了一门新的编程语言java,了解了面向对象的设计方法,初步认识到了到底什么是一个类,学会了如何使用继承、抽象类、多态等写法,学习到了许多设计模式,但实践的并不多只有工厂方法、消费者生产者。学到了新的编程方法:多线程编程,学会了简单控制线程互斥与同步。还了解到了jml这一规格化语言,以及junit单元测试这种逐个方法测试的测试方法,最后还学洗了使用uml类图来构建工程的框架。工程能力毋庸置疑的也得到了很大的提升

    给课程提建议

    • 作业梯度方面。作业难度梯度没有循序渐进,而是“跌宕起伏”。第一次作业时刚刚接触java语言以及面向对象的概念,我觉得更适合那种官方提供一个代码包,然后让同学来继承接口实现代码的作业,而且当时os也不难,大家都有时间、有精力而且还保持着对oo的浓厚兴趣,可以让大家阅读官方给的代码来深刻理解面向对象,理解如何抽象一个类等,或者每次作业后提供官方标程,否则就是全凭理论知识自己摸索,效果并不好。
    • 互测方面。就算代码风格通过checkstyle统一规范,但看着没有注释、没有readme、完全不知道什么思路的代码还是让人头疼,在之后OS难度飙升的情况下花大量的时间去学习阅读别人的代码的人确实少之又少(可能我认识的人都比较懒)。找bug也真的就是锻炼大家搞评测机的能力吧,而且有些代码中很明显的线程方面的bug只靠单次评测可能无法测出,建议多次评测,或者开放人工审核多线程bug窗口,以及规定必须写一个比较完整的readme文件来阐述自己代码的思路(注释就算了,毕竟程序员都不喜欢写注释)。
    • 上机实验方面。建议调整上机实验内容,不要上午学,下午考,留给我们的学习时间很少,而且也只有一次提供了预习文档。

    转载于:https://www.cnblogs.com/eitbar/p/11072826.html

    展开全文
  • oo第四单元总结

    2019-06-24 10:56:00
    oo第四单元总结 1. 总结本单元两次作业的架构设计 第四单元的两次作业都是对UML模型文件进行解析,主要关注类图、顺序图和状态图模型层次的语义观察,UML模型间关系,模型图表达的内容及关系,模型图之间的关系和...

    oo第四单元总结

    1. 总结本单元两次作业的架构设计

    第四单元的两次作业都是对UML模型文件进行解析,主要关注类图、顺序图和状态图模型层次的语义观察,UML模型间关系,模型图表达的内容及关系,模型图之间的关系和一致性检查。

    1.1第一次作业

    第一次作业的主要是完成对UML类图的查询。我的思路是对类和类中的属性和操作用HashMap保存,对于关联,继承和顶级父类,建立静态数组保存类和接口之间的关系。对于函数的调用仅是返回图中的值。这次作业主要是要理解UML解析文件,需要发现如何找到属性和操作对应的类以及继承和关联关系是如何实现的。

    第一次作业中我的代码有两个bug,一是在统计类实现的全部接口时,我用HashMap存接口间的继承关系,在多继承的情况下,会导致有的继承关系没有被记录。二是在类是否违背信息隐藏原则时,应该传出属性所在类的类名,我都传出了传进来的那个类名。对多继承没有使用恰当的保存方式以及对题意理解不充分。

     

    1.2第二次作业

    第二次作业的主要内容是对状态图,顺序图的查询和对类图的三个检查。在这次作业中我复用了第一次作业的代码,但我第一次作业的代码不能处理循环继承的问题,所以在MyUmlGeneralInteraction初始化时会出现死循环,需要更改初始化顺序。

     

     

    2. 总结自己在四个单元中架构设计及OO方法理解的演进

    第一单元

    第一单元我基本没有架构设计,也基本没有任何面向对象的思想,三次作业每次都是重构的,甚至在第三次作业中由于试图用完全的数据结构处理括号问题而差点导致作业无效。

    在第一单元的总结中我从复杂度的角度对比了我第三次作业中用面向对象拆分表达式和用数据结构自底向上建立表达式树的两种方法。发现在建立表达式树的过程中,由于自底向上的求导拼接形式,对于括号的把握也比较困难,并且造成圈复杂度非常高,让程序的质量降低。面向对象的编程可以降低模块间的耦合度,使程序结构化程度提高。

    第二单元

    第二单元我的代码一直是复用的,每次作业只是增加了新的功能。在第二单元中我将问题解耦到电梯类,调度器类等,在多电梯时增加主调度器类,还是有一些面向对象思想的。但我在线程安全方面的做法偏离了“生产者-消费者”模式,采用整体synchronized块的形式保证线程安全,这种设计方法不需要使用wait(),notify()等方法,避免轮询过程可能产生的线程安全问题。但CPU和内存占用相比“生产者-消费者”模式都较多,且伴随请求数量的增加,这中差距更为明显,所以可能并不是一个好方法。

    第三单元

    第三单元JML是规格化设计,提高代码的可维护性。第三单元对架构设计主要就是将所有已知信息归结为图的形式储存起来,再将所有问题通过权值的变化归为最短路径问题,再选择一种合适的处理最短路径问题的算法。在这一单元还需要考虑CPU_time的问题,需要优化图的大小,最短路径的算法以及构建图与指令查询的分离。这一单元我主要学习到设计与实现的分离,感受到JML可以使代码编写的过程更加清晰。

    第四单元

    第四单元主要就是将UML图中的信息用图保存下来,在规定时间复杂度的限制条件下完成题目要求。

    3. 总结自己在四个单元中测试理解与实践的演进

    · 第一、二单元主要是自己构造数据,测试边界条件,第一单元主要是空格和符号问题以及长正则表达式可能会爆栈的问题。第二单元主要是线程安全,电梯间的配合等问题。

    · 第三单元接触了Junit测试和OpenJML测试,感觉Junit在随机数据的配合下确实可以提高代码的正确性,但对于OpenJML我仍然不能从中准确地找到代码的错误。

    · 第四单元主要是自己画mdj文件,寻找边界条件,对代码进行测试。

    在四个单元的测试中,我能感受到测试的重要性,不仅要对代码是否正确进行测试,也要对代码的运行时间合理把握。

    4. 总结自己的课程收获

    · 对java语言有一定了解,从完全不会到能完成一定要求。

    · 在面对一道题目时,能先试图分析解耦题目要求,在有一定架构设计的基础上,再开始编写代码。

    · 了解面向对象和面向过程的区别,体会到面向对象的思维方式在一些较为复杂的问题上的优势。

    · 从多角度理解面向对象的思维方式,从JML,UML等角度理解面向对象的程序设计。

    · 在编写代码时,关注代码的可扩展性,使代码复用更多,降低复杂问题难度。

    · 能关注到代码风格问题,虽然在文件命名规范等问题上还会出现问题,但在大多数方面能符合代码风格要求。

    · 感受到全面的测试对代码编写的重要性,能在写完代码后尽量测试。

    5. 立足于自己的体会给课程提三个具体改进建议

    (1)关于理论课,希望能增加一些与实验课或作业更相关的内容。

    (2)关于强测互测,强测互测中的错误很可能是同质bug,但在强测和互测中各扣一遍分,希望bug修复能改善这个问题。

    (3)关于实验课,对于我这个初学者来说,感觉在实验课上的收获不大,可能是因为上午听过理论课还没有充分理解这部分的知识,也可能是与作业联系不大,没有感到实验课对于写代码的作用。希望能调整一下理论课与实验课的顺序。

    转载于:https://www.cnblogs.com/xpppx/p/11075920.html

    展开全文
  • OO第四单元博客总结

    2019-06-23 00:53:58
    架构设计及OO方法理解的演进2.1 第一单元2.2 第二单元2.3 第三单元2.4 第四单元3. 测试理解与实践的演进4. 课程收获5. 课程的具体改进建议 1. 第四单元两次作业的架构设计 1.1 第一次UML作业 第一次作业的UML架构...
  • 2019OO第四单元总结

    2019-06-24 16:44:00
    一、关于OO第四单元的UML作业的架构设计 在这个单元的作业中,第二次作业只是在第一次作业的基础上增加了一些功能,但在架构上并没有改变,因此这里我主要说第二次作业的架构。 在MyUmlGeneralInteraction类中,...
  • OO第四单元总结~~

    2019-06-24 13:26:00
    OO第四单元总结~~ 紧张刺激的一学期OO课程结束了,咸鱼们留下了悲喜交加的泪水。在说这整个学期的OO感想之前,先总结一下第四单元学到的知识。 一、第四单元总结  这一单元我们学习了UML有关的内容。 首先...
  • OO第四单元博客

    2019-06-20 17:34:00
    第四单元博客 这个单元的作业,emmmm助教们做的工作还是一如既往的多,我们只负责添一添代码,最后一次作业了,感谢各位助教和老师,同时也希望我能顺利通过这最后一关。 架构设计 第一次作业架构展示 第一次作业...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 9,725
精华内容 3,890
关键字:

oo第四单元