1.系统概述

本工程实现了一个简单的葫芦娃大战妖怪的图形化应用，其中涉及了面向对象编程的诸多思想方法，以及文件IO、多线程协同、异常处理、单元测试等机制。

开发环境：Eclipse IDE Photon Release (4.8.0)

运行环境：JDK 1.8

构建环境：Apache Maven 3.6.0

测试环境：JUnit 4

图形化框架：JavaFX 8

2.文件组织与数据结构

2.1 单个生物体类 Creature

继承自Java的Thread类。

其字段存放生物体的共同基本信息，如状态、类别、字符表示、坐标、战斗力等。

其子类为：

CalabashBrother，葫芦娃

GrandFather，老爷爷

ScorpionMonster，蝎子精

SnakeMonster，蛇精

SmallMonster，小妖怪

其主要方法为：

move()，判断下一步的位置，根据该位置的生物存在情况实现移动/挑战/待机等不同的逻辑判断。

run()，重写了Thread类的run()方法实现生物的移动，并利用并发锁的操作Lock.lock()/unlock()和线程通信Condition.await()/signal()来实现多线程的协同。基本框架如下：

while(cond1)

{

lock.lock();//加锁

try{

if(cond2)

con[number].await();//等待上一个线程的信号

else{

move();//做出移动

con[number+1].signal();//向下一个线程发出信号

Thread.yield();//自己让出CPU

}

}

catch(Exceptione){e.printStackTrace();}

finally{lock.unlock();}//finally块中释放锁，这样即便跳出循环块仍然可以执行

}

2.2 生物状态枚举类 Status

实现了四种生物状态：ALIVE-存活, DEAD-阵亡, STOP-停止, EMPTY-空缺。

实际运行的时候，因为没有对阵亡生物做特殊处理，故阵亡和空缺的处理逻辑是一样的。

2.3 棋盘类 Board

在二维空间中放置生物体。

其主要方法为：

findEnemy()，对于给定的生物，判断其四周是否存在敌人

isValid()，判断给定的位置是否不合法

set()，将给定的生物移动到新的位置

show()/showOnly()，将当前棋盘输出到主窗口，区别在于是否保存

load()，读取指定文件中的记录并输出到主窗口

2.4 阵型类 Formation

检查阵型的合理性及按阵型放置生物群。由于基类不存在实例对象，test和set方法均要具体实现，故设计为抽象类。

其子类为：

Snake，长蛇

Goose，雁行

Yoke，冲轭

Crane，鹤翼

其主要方法为：

test()，检查阵型中每个生物体是否都可以放置

set()，基于阵型放置生物体群

2.5 图形界面类 Display

Implements自Initializable接口，实现了图形界面的所有主要操作。

其主要字段为：

一个勾选框，实现背景音乐的开关

三个Button，分别实现开始对战、变换阵型、读取记录的功能

若干Label，每个Label关联到一个图片以实现不同生物体的表示，通过改变Label的坐标实现生物体的移动

其主要方法为：

initialize()，初始化每个Label关联的图片

showOne()，将某个Label显示到特定位置

setInvisible()，将所有Label置为不可见

2.6 上帝类 God

集成各类的对象并进行整体调度。

其主要方法为：

urlToFname()……这是一个很迷的方法，因为maven构建以后的jar采用url加载资源，而url在eclipse和jar运行的时候是不同的，只能退而将之分情况处理，并转化为可以被File类接受的file路径字符串。个人觉得这样的处理方式存在隐患，但一时没有更好的做法。比如maven构建后jar运行时，url=jar:file:/D:/java/FinalProject/target/FinalProject.jar!/pic/test.txt

而eclipse中运行时，url=file:/D:/java/FinalProject/target/classes/pic/test.txt

而我们需要的fileName=D:/java/FinalProject/target/classes/pic/test.txt

changeFormation()，变换妖怪阵营的阵型

run()，将正方阵营和反方阵营的所有线程投入线程池中运行

loadFile()，加载记录文件

2.7 音乐类 Music

为程序添加了背景音乐，聊胜于无。哈，哈，哈。

2.8 主类 Main

创建JavaFX的主窗口，并进行主窗口的初始化，如读取fxml文件、背景填充、组件加载等。

2.9 测试类 TestApp

主要测试了以下的方法:

棋盘上生物的摆放

自动寻找敌人的算法

解析url为绝对路径文件名

按照阵型摆放生物

Eclipse中即可方便地进行JUnit调试，可以报错assert失败的那一行，故没有把各类测试拆开。

2.10 各类之间的关系

其中箭头仅右边生物类中为继承关系，其余部分表示一种依赖与关联。

3.面向对象的思想方法及各类机制

3.1 封装、继承与多态

如Creature类，其封装了内部属性，将某些接口(如获取战斗力)提供给外部调用；自身继承自Thread类，而其子类又继承了其属性并重写了run方法，实现了消息处理的多态。

3.2 抽象类与接口

如Formation类，其自身为一个抽象类，在四种具体的阵型中实现其判断逻辑和摆放方法；再如Display类，其自身为一个实现了Initializable接口的类。

3.3 异常处理

Java强制对IOException进行处理，利用try/catch语句或者向上层调用者throw异常。另外在多线程的协同中，也用到了异常处理模块，特别是在finally中释放锁，可以保证尽管try模块中使用了break跳出循环，仍然可以正确地释放资源。

3.4 注解

程序中有所体现，举例如下：

@Override注解表示子类重写父类方法，如果重载方法则会报错

@SuppressWarnings表示压制警告，一般用于调用已经过时的方法，尽管不推荐使用

@FXML，表示该组件和fxml文件中的组件相关联

@Test等，在单元测试中用到

3.5 文件IO

本工程利用了简单的txt文件保存每一步的战斗结果，保存格式是类似图形界面样式的字符阵。每次运行程序，如果选择读取文件，则读取路径下的test.txt文件；如果选择开始战斗，则清空路径下test.txt文件内容，在每一个生物执行完移动后，将当前棋盘的状态转化为字符表示写入test.txt。

3.6 RTTI的应用

工程中对于资源文件的读取，一开始是使用了根目录的相对路径。这样存在的问题是，生成的jar文件也必须放在根目录。考虑到maven构建后资源文件应当会在classes类目录中生成，故采用了运行时类状态读取文件位置的方法，具体举例如下：

Imageimage=newImage(getClass().getClassLoader().getResourceAsStream("***.jpg"));

ImageViewimageView=newImageView(image);

good.setGraphic(imageView);

3.7 多线程协同

继承Thread类，利用并发锁和线程通信实现协同，在Creatre类中已经分析过，这里不再赘述。

3.8 单元测试

在TestApp类中已经分析过，这里不再赘述。

4.构建、运行与结果

在工程目录下执行 mvn clean test package，结果如下，可见已成功通过单元测试用例，并生成jar包，大小约为4M。

双击运行，程序的主界面如图。提供了三个按钮：开始，变阵和载入，以及一个背景音乐的勾选框。

在程序运行之前，点击变阵可以让妖怪阵营变换阵型。

选择合适的阵型后点击开始，两方阵营均变换阵型向战场中部行动，行动顺序为正方阵营的存活生物->反方阵营的存活生物。当某个生物和其敌对方生物距离过近时，该生物向敌对生物发起挑战，两者会进行以战斗力为基准加上随机因素的判断，若挑战者胜利，则其取代失败者的位置，否则其从战场上移除，且不会影响到被挑战者的行动机会。当某方阵营的生物总数降低到零，程序结束。

点击载入可以加载程序目录下自带的记录文件。注意每次运行程序只能选择开始/载入中的一者。

5.思考和启发

5.1 系统存在的问题

本次实验难度较大，主要是综合了一学期以来方方面面的知识点。限于个人水平和精力，本程序仅仅完成了大部分的基本功能，其鲁棒性、趣味性非常欠缺。一些比较显著的问题整理如下：

将工程放在中文目录下，可能会出现文件操作失败的情况。在eclipse中调试可以得到正确的路径，但实际运行时存在问题，应该是与文件路径的编码有关，最后也没能做到适应。因此请不要在中文路径下打开此工程的jar文件……

违反了一些设计原则，如依赖倒置原则。本工程将棋盘类的实例对象作为一个静态局部变量放到Creature类中，使得所有生物体共享一个棋盘，是为了消息交互的方便起见，但总觉得有更好的处理方法。

战斗过程不甚丰富有趣。生物体的移动和战斗没有更加细致的动画，而仅仅是图片的瞬间移动和瞬间消失，有时让人不知所云。

各模块耦合度过高。对于Java面向对象的消息传递机制和思想理解不够深入，很多地方真的是强行交互，难以做到高度解耦。

多线程操作的鲁棒性较差。如果在战斗开始的过程中，再次点击开始，可能导致一系列意想不到的错误，读取同理。无奈起见，开始和读取的按键在一次运行程序中只能点击一次，强行防止了类似的问题出现。

5.2 一些启发和记录

在艰苦的编写代码、调试bug的过程中，我也受到了很多启发。比如对于多线程编程，之前仅仅在操作系统课程中学习相关理论，并没有真正写过大型的多线程程序。此次多线程基于最简单的生产者-消费者模型实现，一步一步添加模块和逻辑到最终的实现，虽然必然还有更好的实现方法，但本身已经是一种进步，一种读万卷书和行万里路的结合。

这门课程的综合性还在于，让我学会了很多与java编程本身关系没有那么大的东西(尽管理解和掌握都比较浅薄)，如github与git的使用，六大编程思想及数十种编程模式的理解和应用，ReadMe文件的编写，maven构建管理等等。作为一个已经学习两年的程序员，仅仅会写一个main文件是远远不够的，这一系列看似游离于代码之外的东西更考验一个人的综合能力。若干年后面对屏幕上的.java文件，也许我会想起现在的自己。