面向对象设计与构造 Unit4 博客

[曾文轩-22373305]

1 架构设计与UML正向建模

架构设计

本单元实现的是一个图书馆管理系统，其中在官方包中已经帮我们解决好了很多输入输出相关的问题，并且解决了书籍类的存储，所以只需要构建好图书馆各个部门和用户以及它们之间的交互的架构。

实现的结构是：

• Main，即主类，静态类

  只进行调用输入接口进行输入，并把输入进来的请求根据种类分发给控制类的不同parse方法进行处理

• Control，即控制类

  整个结构的核心，负责创建并掌管着图书馆的各个部门。并且针对不同的请求把任务交给各个部门类进行处理。

  • Shelf，即书架类

    存放了书架上的所有书，提供借还书查询的方法

  • BorrowReturn，即借还处类

    存放了放入借还处的书，并且针对，正式书籍、非正式书籍、即将成为正式书籍的书籍，分别存储，方便控制类在进行图书移动的时候分别放到不同的地方，输出不同的信息

  • Appointment，即预约处类

    存放了已取好书和未取好书的预约请求，并每日查询请求是否过期

  • Drift，即漂流角类

    存放了漂流角的书，和书架类基本相同

• School，即用户管理类，静态类

  静态类，管理着所有的用户

  并且提供getUser静态方法，如果users中已有这个学号，则直接获取返回，没有则创建一个新的空白的学号加入users中，并返回

  （写博客的时候发现，这里可以进行优化，因为有一个独立的控制类，事实上只在控制类中调用了School的静态方法，所以不如把School从静态类变成和上面的部门类一样，作为Control类的一个对象，这样还提高了封装性，别的类不能随便调用School）

  • User，即用户类

    存储用户借来了的书和到期时间以及用户的信用，提供了借还书等的方法

集中式控制

经过了OO课程中的训练、上课、研讨、总结，以及自己在不断尝试中的体会，架构思维确实有了提高。

如果这个作业是OOpre的作业，我想我应该大概率不会有控制类，工作基本都在主类完成。

并且，UML类图不会呈现上面的样子，而是依赖关系(Dependency)会漫天飞舞，甚至是“完全图”。

具体的实现上就是，主类完成输入之后，就针对各种请求分发给需要完成工作的对应的那个第一个类，再互相调来调去——比如，预约会先调用Shelf类，调用的同时用参数的形式提供appointment对象，Shelf类检测到有对应的书之后调用Appointment类的方法，Appointment再调用User类的方法等等。

总之是会呈现一个比较分布式的控制，特点是以参数的形式传递各个对象，然后互调。

这次的作业中，就比较好地采用了“民主集中制”的集中式控制，每个部门只完成自己的工作，就交给上级Control，上级再调用另一个部门继续完成。这样整体会显得有序很多，UML图也会简洁清晰的多。

正向建模与开发

Unit3和Unit4主要的工作都是让我们体会设计的思想，尝试并体会从代码思维到设计思维的转变，真正初步学会面向对象设计与构造中的设计。

Unit3是课程组设计好了，要求我们按照已经做好的设计来进行编程，感受设计好了之后的编程和直接的编程的区别。

而Unit4则是让我们自己设计，而设计使用的工具就是UML图建模。

在hw13中第一次使用UML类图进行正向建模时，在实践的过程中可以发现，要想实现真的在一张类图中就能凭空想好所有需要实现的属性和方法及其参数和返回值，之后再依据类图进行实现，还是难度非常大的。

主要的难点的一方面是，有些代码逻辑中很关键的部分，其实并不会以一个属性或方法的形式在UML类图中出现，在UML类图中没法体现出来。没法画出来，就导致了建模过程中的思绪的中断。

比如，控制类是整个架构的核心，但是，在控制类中进行的各种类型的指令的分发并没有形成一个个方法。

在实践正向建模的过程中，实际上的操作是，先在类图中画好基本的需要的类，主要需要存储的对象，核心的方法，并且有一个辅助的文本补充在类图中体现不出来的东西。这样基本设计好了之后，进行coding，最后补充上代码中额外使用的辅助的内容，完成最后的UML图。UML类图和代码形成了一个相互促进的过程。

代码与UML的追踪关系

最后的效果上，各类中的主要业务方法，如inquire、borrow等与设计中的保持基本一致，主要的存储的对象的属性页保持一致，但是存储时使用的数据结构有变化。同时，增加了一些辅助属性，如Control类中的donator属性，用来方便进行书籍升级时，给原捐赠者增加信用分。

2 四个单元的演进

架构设计思维的演进

• Unit1是表达式的解析，这个单元中我经历了一次彻底的重构，尝试了两种差别很大的架构。第一种架构的设计时，我考虑的是怎样“充分利用面向对象的特点”，采用了大量的继承重写和重载，实现了一个二叉树结构，存储的感觉很漂亮。但是这种架构耦合度很高，属于经常要“互相调来调去”，很容易造成混乱。而且对于问题本身也不利于表达式边解析边化简。第二次就取消了这种结构，采取了单一存储，层次化结构。这样就清晰多了，虽然是从头开始写，但是写代码的用时减少了好多倍。
• Unit2做多线程，这个单元在架构设计方面，主要是设计好整个一连串的生产者消费者模式形成的流水线结构。

测试思维的演进

在整个的OO课程中，我尝试并使用了多样的测试方法。

• 构造简单的数据，针对题目中要求的各种情况，进行测试，看看行为是否正确
• 思考一些边界情况、极端情况，构造一些极端的数据，对代码进行边界测试、压力测试。比较典型的有Unit2的“围师必阙”数据，Unit1第一种架构的时候，表达式长度很长，8次方很多的时候的stackoverflow，Unit3当很多query value sum的时候等
• 自动化生成数据，构造评测机，或者像Unit3中学的那种参数化Junit测试，在IDEA中自动构建大量数据测试等
• 对比较容易出错的部分进行瞪眼法，检查各种情况是否出现问题

3 课程收获

经过了OOpre和OO总共5个单元的磨练，从刚开始接触Java和面向对象，在学习和完成作业的过程中，一步步接触在各类中进行的java编程、git的高级用法、Junit测试、正则表达式、继承、接口、编译的思想、多线程同步互斥、读写锁、JML、UML等等，学习了很多知识。同时也一步步体会了设计的思想，从刚开始在写代码的过程中怎样方便怎样来，到慢慢学会设计越来越解耦合、清晰的结构，学会先设计再写代码。除此之外，OO也是大学以来工作量最大的课程，也是对抗压能力锻炼最深的课程（比起CO只有P7折磨了两三周，OO每周连续不断连轴转，对整个身心的锻炼是很大的），同时也是大学里难忘的回忆。OO和大二时光一起结束了，它给我带来了知识、设计思想、能力等各方面的提升。