北航2023秋-oopre结课总结-CSDN博客

本文链接：https://blog.csdn.net/StaCivaFox/article/details/134263579

北航2023秋-oopre结课总结

你说得对，但是oopre课设是一款由我自己自主研发的开放世界冒险游戏，你将扮演一位名为“冒险者”的神秘角色，与其他冒险者相爱相杀，从能new出商品的神奇商店购买装备——同时，逐步发掘“屎山迭代”的真相。

一、架构设计与调整

最终架构设计

在这里插入图片描述

Main类接受输入，将输入传递给Instructions类；Instructions类对输入进行解析处理，获得参数，调用Adventurer类和FightMode类中的相应方法。
- Adventurer类负责所有语义上由单个冒险者完成的动作，如添加、删除、携带、使用、买卖物品，进入战斗模式，攻击和受击等。其中组合了Inventory类和Backpack类，分别负责这一冒险者拥有和携带的物品的相关方法。
- FightMode类负责战斗模式的相关方法。
  - 由于它描述的是冒险者之间的关系，因而包含了管理冒险者们的容器。这一容器由Main类创建并在实例化对象时作为参数传入。
  - 其关联了FightLogAnalysis类，该类专门用来解析每条战斗日志的输入，并将解析得到的参数返回。
Adventurer、Bottle、Equipment、Food类实现了Commodity接口，抽象出它们作为商品时的行为共性。
Store类采用单例模式创建，在向冒险者售出物品时采用了工厂模式创建售出的物品对象。
援助功能通过观察者模式实现。Adventurer类实现了Employer、Employee接口，分别实现被观察者（作为雇主）和观察者（作为雇员）的行为。

迭代过程中的架构调整

第三次作业中进行了一次重构，加入了Inventory类和Backpack类，分别管理冒险者拥有和携带的物品。
此后每次迭代都没有对先前的架构进行大的重构，都是在之前的基础上根据需求扩充新的结构。
- 第四次作业扩充规模较大，增加了与战斗模式相关的诸多个类和方法，在架构设计上费了不小的工夫；好在设计完成后编写代码时没有遇到大的阻碍，相对比较顺利。（这次迭代工作量很大，在新主楼奋战到凌晨，记忆犹新 >_<）
- 第七次作业尝试实践了课上讲到的几种设计模式。

二、使用junit的心得体会

junit可以说是debug的有力辅助。当代码比较复杂时，单靠瞪眼法是很难发现自己程序中的逻辑错误的，这时就需要通过junit有针对性地构建一些特殊的样例进行测试。debug的思想原则之一是，错误的表现形式可能五花八门，但根源很有可能只是某个关键方法的关键逻辑不够完善，这时用junit针对某个方法构造特例进行测试就能很高效地定位问题。

三、学习oopre的心得体会

向面向对象思维的过渡

oopre的迭代作业是我第一个进行的有一定规模的开发，驾驭起来还是有一定挑战。这门课带给我的最大收获就是向面向对象思维的过渡。面向对象更贴近现实生活中的思维方式；当系统具有一定的复杂性时，面向对象思维能有效起到提纲挈领的作用，抓住主要矛盾，不受旁枝末节干扰。

类在设计时要遵循高内聚，低耦合的原则，划清每个类的职责范围，能做的事要做好，超出职责的事坚决不勉强做。
上层在调用下层时只关心谁，做了什么，而不关心具体实现。具体实现的复杂性下放到下层。

设计与编码分离

这门课带给我的另一个收获，就是让我深刻体会到了设计的重要性。从第三次作业开始，每次上手写代码前，我都要先设计好架构并写成设计文档，再根据文档编写代码。这样我写代码时思路就很清晰，过程也很流畅，基本能够保证结构的明确和程序的正确。当然，在实际的编码中肯定会发现一些最初设计时没考虑到的问题，不过也只需要微调设计，而不至乱了阵脚，拆东墙补西墙。这种习惯对于其他课程（比如计组）乃至以后的学习和工作都是有益的。