OO_Unit4 博客总结

魏东霖-22371041 学生 2024-06-11 23:18:24

OO课程的最后一次作业。在前三个单元中，经历了表达式解析、多线程设计、JML建模，而在本单元中又接触了UML，总结来说，几个单元中始终以建模为导向，以设计为主线。下面分几个方面谈一谈我对本学期内容和第四单元内容的一些理解与感受。

第四单元架构总结

在本单元中，由于UML的存在，使得正向建模变为了一件有迹可循的事情。在以往的单元中，大概都是先构思一个整体的框架，然后再缝缝补补，遇到不合适的地方往往还需要推翻重来。但是在本单元中，一方面由于需求比较明确，另一方面提前绘制类图可以使得在设计时就优先兼顾好设计的复杂性与可扩展性，虽然最后也没能实践“完全按照UML中的函数写代码”，但是也算是完整的从零开始体验了一下“正向建模”这个过程。

说几点设计过程中感受比较深的地方吧。

类与类之间的依赖与组合关系。无论是在本次作业中，还是在前几个单元，如何处理好各个类之间负责什么样的任务都是设计中最重要的地方。一个好的设计不应该仅仅是高内聚、低耦合的，还应该是符合直觉和逻辑的。所以我在设计中会尽可能贴近常识做一些设计，比如图书馆中的整理、各个部门的职责等，或者是电梯作业中相应需求的方式等。
类与类之间的数据流动。设计什么样的接口能最好的兼顾传参、阅读与调用，类与类之间能否能够构建一些符合逻辑和常识的调用顺序，这些是我在设计中需要考虑的原则。
减少或合并冗余的类与方法。

最终经过三次迭代，获得了如下的作业架构：

由Library类总体管理借还处CirculationDesk，预约处ReservationCenter，书架BookShelf，图书漂流角ExchangeCorner 。同时，我将官方包中的LibraryBookId包装为Book类，id包装为Student类，以便同时记录一些数据。

数据由Main流向Library，再由其统一管理、分发给各个负责处，各个负责处又可以将不需要的数据返回给Library，实现了数据的循环流动。这是我最开始的设计思路，尽管在几次迭代中略有修改，但是这个总体框架一直沿用了三次作业。最终也通过实践证明了这个架构的可扩展性是非常好的。

// Library 中数据的分发
public void processRequest(LibraryRequest request) {
    switch (request.getType()) {
        case QUERIED:
            queryBookInfo(Book.convertBookId(request.getBookId()));
            break;
        case BORROWED:
            borrowOneBook(request);
            break;
        case ORDERED:
            orderOneBook(request);
            break;
        case RETURNED:
            returnOneBook(request);
            break;
        case DONATED:
            donateOneBook(request);
            break;
        case RENEWED:
            renewOneBook(request);
            break;
        case PICKED:
            pickOneBook(request);
            break;
        default:
            break;
    }
}

四个单元中设计思维的演进

首先，迭代开发很考验每一次的架构设计。因为如果上一次的架构不尽人意，那么下一次作业必然是很痛苦的。因此每一次的开发中必须重视分层与接口的设计。正如我之前每次博客中都强调的“需求-实现”模型，我很喜欢这样的设计方式，通过需求来指导实现，而最终的实现一定会高于需求。同时在设计时还要充分考虑各个部分的可扩展性，为下一次的迭代做好准备。

一个比较良好的例子是一单元的Expresson - Term - Factor这样的模型，可以看到这样的设计框架几乎是满足了所有的扩展需求，实践证明在后续的迭代中没有出现大的框架改动。这充分说明了好的设计可以帮助开发者减少大量的后续工作量。

而我个人不太满意的则是电梯单元中我的设计，自从第一次作业到最后一次作业，几乎每次都需要改动挺大一部分的架构，当然这可能是刚刚接触多线程时不熟练导致的，不过事后回想起来当时确实没有仔细阅读往届博客认真做设计。

总的来说，设计是本学期课程中训练最多的点，也是我觉得收获最大的部分，它使我更重视功能与层次的抽象，也让我摒弃了上来就写代码，边写边设计的习惯。

四个单元中测试思维的演进

首先感谢DPO测试组的所有同学，感谢他们的所有付出和努力

一直以来，我的测试都主要是手搓一些比较有代表性的数据点，但是无论是上学期的计算机组成课程设计还是本学期的OO，都让我认识到了手搓数据的不足——数据量小、测试覆盖面小，更无法做到压力测试等针对性能的测试。因此自动化测试的重要性就体现在它能使用黑箱的方式提交大量的输入并完成输出数据的正确性检测，省事的同时也很大程度上弥补了手动生成数据的不全面问题。

但是本学期让我意识到的一个很重要的问题是——测试永远不会是完全的，测试也永远不能证明程序就是正确的。无论是过分相信测试导致的bug没有检查出来，还是其他的问题，都在说明测试不能保证程序的质量和准确，我们只能不断的逼近正确，可什么时候能到达最终的那个终点呢？可能唯有从设计、编写再到测试等方方面面都保证质量，才能真正保证软件或者代码的高质量吧。

一点感想

特别感谢所有老师和助教在这段时间的付出，感谢带来的精彩OO课程。

有时回想起第一次下载IDEA的时候，那是第一次写Java代码，以及后来参加的第一次强测，第一次撰写博客......这些事情发生在半年前，可是又那么像就发生在前不久。回过神来发现OO正课已经接近尾声，看着总共十六次的作业，我有点语无伦次的想说明经历过这一切的感受。可能我真的做到了什么吧，从背起行囊到回头眺望，我已经走了很远了啊。

...全文