面向对象设计与构造第四单元总结

大佬教程收集整理的这篇文章主要介绍了面向对象设计与构造第四单元总结，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。

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

1.1 架构内容

在本单元的架构中，我主要还是根据实际需求来编写。出现了类图、状态图、顺序图三种不同的图，可以考虑针对三种不同的查询建立三个不同的类。但在根据指令的需求，感觉代码重复性太高，没有那么做。指令的询问只针对于Class，Interaction，StateMachine，也因此，只需要向这三者发起询问即可。

根据实际的UML需求，层次非常明显，可以采取按层次遍历的方式来对所有的元素进行解析。

//放弃写mermaid图
class/interface-->operation/attribute/association/associationEnd
				operation-->parameter
				association-->associationEnd
collaboration-->interaction-->lifeline
stateMachine-->state/transition

创建@H_172_5@myDataBase类，用于对传入的元素进行解析，同时存储在不同的容器中，向@H_172_5@myGeneralInteraction提供getClass、getStateMachine、geTinteraction这三个判重再返回的方法。

创建@H_172_5@mychecker类，从@H_172_5@myDataBase处获得需要的数据容器，依次进行检查。

1.2 UML图

图中出现了两个自定义的异常：

myTypeException：
	类型异常，用来统一attributeType和parameterType，避免代码的重复
MyDuplicatedException:
	用于在递归的时候抛出重复，（可能创建多个不同的duplicatedException比较好）

1.3 容器选择

根据查询的需求，容器的选择还是值得一说。有不少地方需要查询是否重名，也有不少的地方需要根据id去获得相应的元素。于是乎，三次作业中，我几乎所有的数据都是用hashmap存储的，查询比较方便。如：

public final HashMap<String, List<MyClass>> name2classes;	//方便判断重名
public final HashMap<String, MyClass> id2class;

1.4 降低复杂度

尽管刻意关注了复杂度，但还是在第十三次作业被偷袭了。获取一个类实现的所有接口处，考虑不够周全，导致出现了类似n^n的复杂度。复杂度较高的主要问题是反复查询一个已经被查询过了的对象，进行相应的记忆化处理即可，在第一次查询过后在该对象中保存查询结果，这样下次查询的复杂度为O(1)，这在本次作业中可以用于：查找所有实现的接口，查找接口是否重复实现等查询方法上。在判断图的循环上，我用了类似拓扑排序的方式进行，依次删除没有入度 xor 没有出度的点，复杂度能够降低很多，尽管dfs可能也不会超时，但更多的是一种性能上的安心。

1.5 关于架构

个人感觉我这次作业的架构并不算特别好，尽管具有一定的层次性，但耦合性有所上升，部分类并没有做到各司其职，可能需要进一步改进才好。

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

• 第一单元

  • 求导整个过程的层次化需求构建了数据类的层次化，遵循表达式、项、因子的层次结构，逐层构建与求导

  • 采取递归下降的方式完成树的构建，在局部使用正则表达式来简化代码

  • 尝试使用接口和抽象类把类的共同点给抽象出来，用多态来统一

  • UML：

    

• 第二单元

  • 第二单元架构设计中的关注点如下：

    • 线程安全：防止并发错误
    • 设计模式：策略模式、生产者—消费者模式等
    • 类的单责性，尽量实现封装，类之间各司其职

  • 调度策略的设计

    • 分布式调度，结构具有层次化特点，可以进行共同管理
    • 关注调度的算法，以减少电梯运行的总时间、减少乘客的等待时间为目的，以充分调度电梯、速度块且可达的电梯优先为方法

  • UML：（舍去各种strategy和scheduler）

    

• 第三单元

  • 本单元基本为实现官方的接口，没有什么可以架构的

  • 如果有的话，主要是对容器进行选择，采取合适的算法进行存储和查询，防止TLE

  • 本单元主要目的是保持程序的行为和JML规格的一致性

  • UML：

    

• 第四单元

  • 见上。

• OO方法

  • 方法的选择应根据需求来定
  • 继承和多态的使用应该合理，满足架构的需要。对于明显层次化的内容，采用一个“管理者”来进行管理在多数时候是很有必要的。
  • 诸如工厂模式等方法，也是建立在需求的基础上的，适当的采用能够让代码更加清晰。
  • 封装是一个重要的特性，单责十分重要。

三、测试理解与实践的演进

• 一开始对测试，还仅停留在传统的手动测试+自动测试，可以看作是盲目的黑盒测试，但也能帮助发现尚未意识到的错误。
  • 手动编写数据，查看输出结果；
  • 构造随机样例，用jar包或者就在类里直接进行测试。
• 后续尝试使用Junit进行单元测试，更加具有针对性
• 测试的方式主要根据需求来决定，根据需求选择较为适合的数据和方式。
  • 对于有严格限定条件的，主要考虑测试数据的全面性，多进行随机样例的生成
  • 对于高复杂的度的，主要手动构造极端样例，来检验是否会CLTE
  • 对于线程安全，需要首先研究是否存在可能死锁的地方，其次才是测试样例

四、课程收获

1. checkstyle带来了一种良好的代码风格
2. 对java的各项功能更加熟悉，尝试从官方doc中获取所需的信息。更多的尝试封装和多态，继承和实现多数情况下并用。
3. 尝试进行代码的设计和架构，然后才开始进行代码的编写
4. 尝试进行需求的预测，考虑架构的合理些，向高内聚、低耦合迈进。整个过程可以思考很多。
5. 学到了很多设计模式。
6. 学到了如何面向对象设计程序，尝试解决并发的问题，构造线程安全类。

五、课程具体改进建议

1. 关于JML
   • 还是希望JML能够更深一些。本单元仅局限于读懂简单的JML规格，照着JML进行代码编写的重复工作，实验也停留在补充JML的阶段，能够学到的东西其实并不算多。或许可以尝试对某些方法要求写出完整的规格，或者把Junit的内容也加入到本单元中，把Junit的编写纳入到公测中去。
2. 关于UML
   • 在完成本单元作业的过程中，我感受到的更多是一种行为的未定义。如同我不知道一个元素在parentId或referencEID存在时，应该怎样处理这个元素。尽管指导书已经相对比较详细了，但仍然会有许多未解释的内容。这点从讨论区所发的讨论帖的数量就可以看出来。希望本单元稍微向JML靠拢，对于内容的解释更加完善一些。
3. 关于实验
   • 实验结束后，一切安详，或许并不是件好事。实验后不知道实验答案，实验的意义可能就少了很多了。
4. 第四单元没有互测，那就不妨早点公布强测结果，能够更好地规划时间。
5. 课程网站建议增加层中回复的，这样在查看回答的时候更加容易找到。
6. 同ch所说，分享与得分最好不要捆绑。至少从我听这么多次分享的感受来看，分享并不能说明什么。分享理应作为一种主动的行为，而不是出于得分的目的性。

大佬总结

以上是大佬教程为你收集整理的面向对象设计与构造第四单元总结全部内容，希望文章能够帮你解决面向对象设计与构造第四单元总结所遇到的程序开发问题。

如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。

本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。