OO UNIT4

22373244-袁耀武

已于 2024-06-11 22:50:17 修改

阅读量1.8k

点赞数 22

文章标签： java

于 2024-06-11 22:45:45 首次发布

本文链接：https://blog.csdn.net/weixin_73803533/article/details/139610443

版权

文章目录

1. 前言

在这学期面向对象编程课程的最后阶段，第四单元如同华丽的终章，奏响了整个学期知识的交响曲。此刻，我借这篇博客之笔，不仅是对第四单元的深情回顾，更是对一学年面向对象学习旅程的诗意总结。

2. 第四单元分析

2.1 正向建模与开发

本单元重点是让我们实践先设计再编程的思想。上课时，老师也强调，oo的学生大概可以分为3类，第一类完全不设计，一开始就闷头写代码；第二类，边设计边写代码；第三类属于“理想型”，一定要设计完全才开始写代码。在学习完本单元后，我和老师的观点一致，认为第二类采取的方法更符合现实情况，也相对更加高效。

然而，在做本单元第一次作业时，我对 UML建模是不理解的，因为我感觉这次作业工作量，思维量并不是很大，完全上来就写代码，而略去设计的步骤。但是在之后的作业中，由于题目要求实现的功能越加复杂化，显然正常人已经无法仅仅在脑中便可以构思出解决该问题的方法，直到这是我才意识到UML的建模的重要性与必要性。UML建模通过对开发的项目进行更高级别的抽象来在我们实际编写代码中起着重要的指导作用。本单元的类图，状态图，顺序图便是一个极佳的正向建模与开发工具。

类图展示了代码的静态结构，标注了每个类的属性、方法、接口和类之间的关系，用于辅助面向对象设计。
状态图展示了对象的状态变化，将复杂的逻辑通过图示的方法信息化，更便于理解，可用于直到类的方法的具体实现。
顺序图展示了系统的动态行为，明确了类和对象之间的交互过程和消息的传递顺序，在调试和维护的过程中更容易理解和追踪系统的运行逻辑。

2.2 架构设计

相对前面三个单元，本单元的类图要简单不少，如图所示，笔者只设计了4个类来完成所有功能，且迭代性较好，在三次作业中均没有重构。

在这里插入图片描述

本架构的核心类是Library类，该类包括了书架，预约处，借还处，漂流角和用户数据库，此外还有一些用户的预约信息。
Main类用来负责处理输入，并根据调用Library类的方法返回的信息进行相应输出。
Book类有多个实例化对象，内部封装了诸如dueTime，donator之类的属性以及setDonator之类的功能，使得其可以充分地表示大多数业务下的书籍信息，具有极强的复用性。
User也有多个实例化对象，内部封装了诸如credit，books之类的属性以及addBookr之类的功能，使得其可以充分地表示大多数业务下的用户信息。

虽然有UML图的正向建模过程。但是正向建模设计的过程并不没有顾及到具体的实现过程，包括实现所用语言上的限制等等。所以在实现过程当中还要根据遇到的具体问题对于之前已有的UML设计进行一定的修改。

3. 单元思维演进

3.1 架构思维演进

各个单元架构思维演进：

在第一单元，我学习到了层次化设计的思想。就我理解而言，Java的层次化设计思想通过将系统分解为多个层次，使得系统更加模块化、易于维护和扩展。每一层都有明确的职责，从而提高了代码的可读性和可维护性。如这一单元解析表达式时采用先解析再计算的方法。
在第二单元中，我学习了多线程程序的设计方法，包括继承Thread类和实现Runnable接口来创建线程，使用sychronized关键字来使得线程同步，用wait(), notify()，和 notifyAll()实现线程通信等等。
在第三单元中，我学习了规格化设计思想。在这一单元我初次接触了JML这种规格化语言。在这之前，我很少认真写注释或者文档，通过对规格化设计的学习，我意识到了与他人协作时规格的重要性，注重起了代码的可读性以及注释的质量。
在第四单元中，我学习了正向建模思想。Java正向建模是一种自顶向下的设计方法，主要用于从需求分析到代码实现的全过程。在第四单元，我们接手了一个图书馆管理系统的开发任务，极大地锻炼了我们对整体进行全面严密的设计思考的能力。

总的来说，架构设计的最终目的是为了服务业务，业务需求，以及潜在的拓展可能决定了有怎样的架构。

3.2 测试思维演进

谈起测试，我最开始的印象就是把一个数据点复制到控制台运行然后看看结果是否正确。通过OO课程的敲打，我发现这种测试方法相对低效，搭建评测机进行大量测试则是一个相对高效的方法。在这过程中，我认识到，测试不应是前面讲到的简单复制，而是涵盖了生成输入，运行环境，获取输出，判断正确性等等流程。除了这种方法外，我试过自己手搓一些比较极端的数据，比如第三单元构造几千条qtvs，对自己的代码进行压力测试。然后我还会和我的朋友进行互测，也就是白盒测试。

但是，尽管测试方法多种多样，但我们不可能通过测试发现所有问题，因此我们也不应该通过测试保证产品的质量。这要求我们在开始编写程序时就应该头脑清楚，充分考虑所有可能的情况。