标签：OO Java 总结报告 代码 电梯 实验 可以 单元

一. 第四单元架构设计

本着轻松愉快的思想，我在做第四单元时没有做架构设计（我知道可以利用中间层次来建立树形、图形结构来减少时间复杂度，但数据量太小了，完全没有必要），所以就去实现所要求的方法，每个都遍历来做。我的确用了一个别的类来提高代码复用性（将像是寻找Class/Interaction之类的方法），但这主要是为了让类的行数不超过500行，我一开始都是放在一起的，但代码太长了只好放到别的类里面了。
本次实验中我尝试使用了stream来完成要求，这样代码书写起来很愉快，最后得到的代码可读性也要比利用分支很迭代写出来的高很多。当然，这种每次都遍历的策略势必会导致复杂度爆炸，但能过本次作业就行了。

二. OO思想在实验中的递进

多项式化简

一开始给人的感觉就是难度很高，但难度位置不太对。第一次实验最为重要的是算法面的思想，我是采用了递归下降法。OO思想主要体现在对数据的管理上，我们应该怎么安排数据之间的关联关系。通过递归的管理数据，我们能够管理嵌套的数据。当然对数据的管理也是OO很重要的话题，我这里采用了一种通用的类来管理所有的项，再对一致的项进行运算与输出格式化。

电梯

第二次实验为我们介绍了Java的多线程机制，我采用的是经典的生产者-消费者模式来书写代码。实验中横向与纵向的电梯，以及相应的横向、纵向的调度器，这些元素之间有着很强的相关性，与之对应的是可以采用继承或实现的方式来增强代码复用性。这个单元可以实验不同的多线程设计范式，也对类与继承有要求。

规格化设计

第三次实验提供了一个现有的元素层次关系，我们需要的是去安排恰当的中间数据来增强对结果的维护，使得数据能够在要求的时间复杂度中得出。OO的结构是由课程组安排好的，我们只用去实现相应结构。已经给出的部分是很好的OO思想的体现，而缓存中间变量来提升程序性能感觉更是算法段的思路。

UML解析器

第四次作业可以不依靠任何结构进行。当然也可以使用结构来构建，只是感觉这次实验没什么这方面的导向。

三. 测试思想在OO中的应用

我只在第二次与第三次中使用了自动化测试工具（结果就是第一次与第四次都有挂掉的点，由此可见测试还是很重要的）。
第二次实验中我构造了随机的数据生成器，并搭了用于检验合法性的测评机。主要思路是去看电梯和人的表现是否合法，以及检验程序是否能正常终止。合法性检验是相对于对对象建了一个有限自动机，来检查每一步转移与结果的合法性。但是最后还是被hack掉了一组数据，只能说随机黑盒数据还是太弱了一点。
第三次作业也是随机的数据生成器，但是对于几个复杂度较高的指令，我专门生成了一些策略来看时间是否超标（事实证明这是十分有用的，因为我一开始Dijkstra写错了，导致复杂度假了，通过相应测例我发现了这个错误）。正确性检验中我是与其他人对拍进行的（因为真要写评测机的话难度与这次作业是几乎相同的），最后通过对拍我发现了一些十分低级的错误，最后能够在这次作业中全对（部分原因也是有JML后本来程序也不大可能错，只是理解上有偏差或者写错了才会导致错误）。

四. 课程收获

首先是会写Java了，因为之前写过一点C++，上手Java还比较快，毕竟语法方面非常类似，只是要去熟悉一切都是对象的语言风格，以及熟悉对象使用都是引用的风格。总体来说会写简单的Java代码了。
然后是学会了一些面向对象的设计模式，这些设计模式更像是一些范式，可以在所有语言中通用。这些思想应该才是本门课程的核心，而Java则只是一个实践的载体。了解设计模式可以写出各项性能更好的代码。
这门课程还有研讨课，增添了与其他人一起讨论设计方案，分析代码，可以从其他人学会很多。
平时学习一些算法、模式也需要上网搜索资料，我的递归下降就是借鉴了网上的代码写出来的。像是后面的一些算法部分也需要查找资料才能写出来。

五. 对课程组的建议

• 架构的体现在整个流程中体现不够。如果想的话，可以几乎不用继承与实现依然可以写的很愉快（除开第三次作业，但里面的继承是作业所要求的，应该抛开它不谈）。虽然说OO的方法论只是能够减少码量增强可读性，是可以避开的。但在实践中对于避开这些方法的负反馈不够大，不足以体现这些方法的重要性。比如哦在第一次作业中，可以增加项的多样性来体现让它们实现共同的接口的重要性，现在我们可以把每一个项用一个统一的形式表达（如\(a\prod \sin^p(term)\prod\cos^q(term)\)），通过这种方式我们就绕开了实现。我觉得增添项可以部分解决这个问题
• 第二次实验还是太简单了（×），我感觉可以增添电梯的多样性。第一点所提到的问题依然存在。我在增添横向电梯写代码时一开始打算让两种电梯继承一个统一的电梯，最后发现这样做的难度甚至高于直接复制粘贴在微调。如果考虑上面的论点，这是十分不合理的现象。也许增添电梯种类可以抑制这种行为
• JML太难用了（我也不知道替代方案，这条建议不算）
• 我不是很清楚第四次实验的宗旨是什么，就我个人而言，我觉得这次实验太宽松了，不太有训练价值（也许也有临近期末的原因在里面）。我觉得可以做个折中，通过加大数据量强制要求维护图结构，这个地方也可以体现继承，我们的结点是要去继承官方包中的，然后适当减少指令条数来使工作量不会太大。

标签：OO,Java,总结报告,代码,电梯,实验,可以,单元
来源： https://www.cnblogs.com/godel-bach/p/16411661.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。