BUAA_OO_Unit4

齐欣宇22371342 学生 2024-06-16 09:11:54

正向建模与开发

本单元我们主要是实现了一个图书馆交互系统。
笨人并没有使用官方包的方法，选择了自己设计，正向建模。
根据需求，我的分析判断是，单元任务将围绕图书馆展开。
载体是书，消费者是用户，图书馆是集中的行为发生地点。
由此可以设计四个基本类，即Main，Book，User，Library。
且为了方便判断指令和书本类型，还添加枚举类Type。
载体是书，Book应当作为一个“被持有”的对象，只记录自身信息。
主体是Library，客体是User，对应的一些关于书的移动操作应当在两类中都有存在。
这样就构成了我的整个模型，此后的代码设计都在这上面展开。

架构设计，对比分析代码设计和UML模型设计之间的追踪关系

话不多说，上类图

代码段基本逻辑很简单，即
Main函数对输入指令进行切分处理后传给Library
Library根据对应指令执行各种操作
其余都是对信息的存储类和方便管理的功能类
主要行为逻辑都集中在Library中

在画类图的时候，一些类之间的关系其实就已经提前想好了
之后进行代码攥写就有留一份心思，这样的关系如何去实现
以及如果有过深的关系，不符合原来的类图，究竟合不合理
是要改类图还是代码。
如此保持思考，代码和类图之间相互关连，并能同步反馈，也可以让架构逐步清晰。

架构设计思维的演进

在本学期刚开始时，我对代码任务的完成更多是问题导向，即
题目需要解决什么问题，我就写出这样的方法
这样做的好处很明显，就是问题刚出来且并不复杂的时候解决起来会很快
而缺点也是显而易见，那就是之后的迭代和维护会非常困难
以至于前两个单元我甚至出现了第二三次作业难以下手过中测的情况
故而在后面的作业中进行反思
开始主动思考可能出现的迭代要求，预留足够的设计空间
以及逐渐形成高内聚、低耦合的代码行为
降低代码之间的关联程度防止大规模重构
到第四单元，我就像是在一个核心模块上面增加功能组件
可以在并不改动核心框架下，只增添几个方法即可完成迭代

测试思维的演进

除了对代码的书写，如何对实现好的代码进行测试也是关键的一环
可以发现，课程组也是十分注重锻炼我们的测试思维
其中强测和互测更是把“测试”二字印在了我们脑门上
不会测试，你就算不上合格
开始的时候停留在简单的编写数据上
最多考虑一些极端情况，如0和2^32-1或者越界这样的数据
但是联系到上学期的Junit测试，可以想到
要学会对方法的功能性测试
先对部分方法的功能进行逐步测试后再测试总体
此外就是考虑逻辑行为中涉及的中间量
有可能通过错误的解法得到正确的结果，这样就需要针对测试