面向对象设计与构造先导总结

[何炫熠-24371385]

一、迭代设计过程

最终设计：

 

1.阶段一：摸索阶段（hw1~4）

在本阶段中主要是熟悉Java和面向对象设计的过程，因此处理的不好，主要出现了以下几个问题：

• 没有搞清楚携带和拥有的区别，统一使用一个 bag 存放
• 权责暧昧，类之间耦合严重，例如Adventurer使用物品是由冒险者来判断物品类型，这就导致如果需要增加物品种类等等维护困难
• 对于总控类没有单独对每个指令设置方法，而是直接写在主方法中，导致主方法行数过多

2.阶段二：重构（hw5）

在本节我确信如果不重构将会无法维护，在学习了工厂模式之后进行了调整，对冒险者划分了wareHouse、bag、bottleBag 三个存储区，以符合 ti 指令的需求，同时将死亡判定完全交由冒险者类（此前是在总控类），重构后个人认为对后面的扩展产生了不小的帮助

3.阶段三：步入正轨（hw6~7）

本阶段基本能够直接根据需求添加，修改比较少，但是也暴露出一些问题，例如删除物品时忘记对 bottleBag 进行清理，事实上bottleBag和 bag 的功能有所重合，因此过于松散也并非好事，需要在其中追求平衡

二、测试心得

1.在 vscode 上使用Junit

必要插件：Extension Pack for Java

（1）按 ctrl + shift + P 展开，搜索Java:Go To Test

 （2）选择生成测试

 （3）右下角弹出提示，选择允许测试

 （4）选择 Junit 后就可以导入包了

 （5）导入包后，点开自己需要测试的 java 文件，再次go to test，会提示输入test文件名字，如果已经有一定的方法，还会让你勾选需要测试的方法（方便起见可以全选）

（6）编写完成测试程序后，可以点代码行旁边的播放键进行测试，类名旁边的是对文件内全部测试，或者右键目录栏，进行覆盖率测试和运行测试

2.测试思路

（1）单元测试

针对单个方法进行测试，可以直接按照课程文档对于每种行为的描述进行编写，比较直观

（2）行为测试

针对某种特殊情况统一测试，例如对写一个测试统一测试冒险者的死亡，看看死亡之后是否不再产生行为

（3）评测测试

根据项目构造方法，将评测数据点转化成相应的测试输入（可以通过写格式转化程序或者AI辅助）

三、面向对象思想的学习总结

面向对象的设计是处理类似实际问题是很好的组织方式，不是对每个细节都追根究底，而是站在当前某个类（角色）的视角，利用有限的数据发出有限的行为，大大简化了问题。

类——种类，即拥有相似表现的一类事物

对象——具体的某个事物，一个对象可以属于多个类别

数据——事物的固有属性

方法——事物的行为

在此基础上，利用封装保护事物的固有属性不被随意改动（只能是在自身允许的情况下），利用继承实现代码复用（也可以在维护时针对改动的类进行修改，而不需要对多个子类进行修改，后者容易有错漏），同时通过多态满足对象在不同场景下的服务

接口的利用是针对行为的管理，而继承还包括了数据层。

工厂模式和观察者模式都是将物品类（或者说是具有相同特征的可能会作为被管理数据的类）进一步抽象，降低耦合程度，明晰权责划分的方法。工厂模式针对的是被管理类的构造，观察者模式针对的是被管理类与管理类的交互行为，这两种模式都进一步地将当前的视角缩小（解耦合），提高可维护性

词法和语法分析问题中，同样也需要不断地转换视角、拉近视角，采用的递归下降个人认为可以理解为递归+自顶向下的思想，步骤为处理当前局部问题->向下扩展->回收总结，与递归的方法大体类似

以面向对象思想的设计和构造方法可以总结如下：

1.根据需求划分不同的类（通常此时可以基本确定继承关系）

2.站在类内的角度，以事物的属性和行为，定义数据与方法，在涉及到类外的交互，均采用抽象方法的形式（例如接口、使用工厂类），不关注具体实现

3.整体组织，并根据需求的更新循环1~3

换句话说，就是产生需求->造零件->组装的过程，相对于面向过程的编程而言，面向对象往往不能在一开始就能很明确的形成完整的流程，同时也拥有了比面向过程更灵活的扩展性，面向过程通常是环环相扣的，而面向对象则强调解开耦合，便于往里加东西，更符合实际业务场景的需求

四、想对课程组说的话

无