oopre总结反思

1.架构设计

架构设计如图：

Main:

主类，整个程序的入口，由于我不会对scanner进行测试，所以我将读入过程也放到这里实现。

Hash:

管理冒险者，分析主类中读入的指令，进入不同分支进行相应操作。

Adventure:

冒险者类，其中包含冒险者的各种属性以及要用到的方法。

Backpack:

背包类，在冒险者类中应用，实现题目中背包相关的操作。

Bottle:

通过继承得到RegularBottle，ReinforcedBottle,RecoverBottle三个子类，实现药水瓶的相关操作。

Equipment:

通过继承得到RegularEquipment,CritEquipment,EpicEquipment三个子类，实现装备的有关操作。

Food:

食物类，实现食物的相关操作。

Store:

商店类，单例模式，实现购买卖出的一些操作

Ob/Subject/Commodity:

三个接口，其中Ob与Subject是我自己为了熟悉观察者模式而特意使用的，其实想要实现其具备的功能不用接口也可以。

Commodity是价值体接口，考虑到Adventure,Bottle,Equipment,Food类都被视为价值体，都有一些相同的操作，如取价值等，因此设计了这样一个接口（其实也不是必须的）。

在整个设计的过程中，我基本没有对整体结构做大的改动，Hash类是在最初就有的构想，这一点想到的比很多同学早一些。目前自己看着整体结构还说的过去，不过在上完第八次课之后，我发现自己的架构还是有很多瑕疵，比如对Hash的功能定位并不明确，内部存在很多存在依恋情结的方法，以及缺少中间人，导致自己的代码读上去有种冗余的感觉，之后还会对代码进一步修改。

2.junit使用反思

说实话，在整个学习过程中，我对junit的使用频率不高，更多的时候还是觉得它麻烦，想通过直接看代码的方式来debug。可是，java不像c那样能很好地去观测过程中变量的改变，而且任务规模的扩大也使得过程变得更加复杂。这就导致了很多时候debug很困难，因为很难确定错误位置在哪。在这种时候单元测试就显得尤其重要了，因为junit能够实现每个类每个方法的单独测试，只要数据覆盖的足够全面，我们便能充分检验方法的正确性。现在我使用junit存在的问题是构造的数据不够全面，测试思想掌握的不熟，编写的程序结构不好导致测试不好进行。希望能够在正课前改正这些问题，充分掌握测试的方法思想。

3.oopre学习心得

首先，经过了oopre的学习，我对代码风格更加注意了，之前自己写的代码没有一个统一的格式，很容易在读代码时出现问题。经过了oopre的练习之后，我现在不论写什么代码都会注意一下代码风格的问题，好的代码风格不仅方便他人理解你自己的程序，还方便自己debug。

其次，在我眼中，面向对象思想与大一时面向过程的编程思想截然不同，在刚学习时，很难从之前的思想中跳出来，感觉很别扭。但随着逐步的了解，我发现，这种面向对象的思想才是更适合实际工程的方法思想。因为实际工程中，我们不可能只解决单一问题，我们要解决的是很多问题的综合，这是系统性的，多元性的。我认为，面向对象这种“分治”式的思想，方便我们对工程进行分解，从而化繁为简，解决问题。同时，这也使得庞大的工程更好维护，提高效率。因此，更好地掌握面向对象的思想对以后我们工作有很大帮助。

4.对oopre的建议

1.课上可以增加对测试的讲解与教学。

2.可以在课程中多讲一下面向对象思想与我们先前学的面向过程编程的不同之处，帮助学生更好过渡。