士兵扫雷源码php技巧_Java扫雷游戏的设计与实现论文源码包调试成功

UDC _______________ 学号_ _

毕业设计（论文）

论文题目

JAVA扫雷游戏的设计与实现

Thesis Topic

Design and Implementation of Mine Game

毕业设计（论文）任务书

毕业设计（论文）题目：JAVA扫雷游戏的设计与实现毕业设计（论文）哀求及原始数据（资料）：1．学习和节制打算机编程干系的基本知识；2．理解和利用JAVA面向工具的特色；3．熟习JAVA的可移植性，跨平台性等多种特性；4．设计并实现扫雷游戏的基本功能；5．深入剖析扫雷游戏的算法实现；6．演习检索文献资料和利用文献资料的能力；7．演习撰写技能文档与学位论文的能力。

毕业设计（论文）紧张内容：1．进行可行性剖析以及需求剖析；2．论述毕业设计所需开拓环境以及开拓工具；3．实现程序的概要设计； 4．在概要设计的根本上进行详细设计，编写实现各个类；5. 展示JAVA编程的扫雷游戏源代码；6．进行系统测试。
学生应交出的设计文件（论文）：1．内容完全、层次清晰、阐述流畅、排版规范的毕业设计论文；2．包括毕业设计论文、源程序等内容在内的毕业设计电子文档及其它干系材料。

紧张参考文献（资料）：秦亮. 利用JAVA实现扫雷游戏的算法解析. 软件开拓与设计（2011年06期）张洪斌. JAVA2高等程序设计[M]. 中科多媒体出版社，2010孙鑫. JAVA WEB 开拓详解[M]. 电子工业出版社， 2006.189-274萨师煊，王珊. 数据库系统概论（第三版）[M]. 北京：高档教诲出版社，2009.王家华. 软件工程[M]. 东北大学出版社，2012尹伟民. JAVA程序设计之网络编程. 北京：中国电力出版社， 2009赵生慧. JAVA面向工具程序设计. 北京：高档教诲出版社， 2010王梅. JAVA并发程序—设计原则与模式. 北京：中国电力出版社， 2008JON TITUS. ECN TECHNICAL EDITOR: “THE ECLIPSE OF STAND[J]. JOURNAL OF ZHONGKAI AGROTECHNICAL COLLEGE” , VOL.19,NO.2, 2006.W.CLAY,RICHARDSON,DONALD,”AVONDOLIO. THE JAVA HIGH CLASS WEAVES A DISTANCE: JDK 5”, SCIENTIFIC & TECHNOLOGY BOOK REVIEW,NO.3,2006ALICE WOUDHUYSEN.CHINA INTERNET:THE LONG MARCH TOWARD E-COMMERCE[J].THEECONOMIST INTELLIGENCE UNIT. 2007

Java扫雷游戏的设计与实现

扫雷这款游戏有着很长的历史，从扫雷被开拓出来到现在进行了无数次的优化，这款游戏变得越来越让人爱不释手了，大略的玩法在加上一个好看的游戏界面，每一处的细节都表示了扫雷的魅力。
以是本次的毕业设计我将开拓一款扫雷游戏。

本次毕业设计因此JAVA措辞作为开拓环境，利用Eclipse设计并开拓一个类似Windows扫雷的游戏，实现其基本功能。
论文首先先容了课题背景，其次进行了需求剖析及可行性剖析；然后设计游戏流程，先容雷区中的雷怎么安顿和产生雷的随机算法；末了先容游戏中可能会触发的各种韶光，比如鼠标点击韶光和清理掉没有雷的格子，个中鼠标事宜包括点击到或没有点击到雷触发的事宜和点击到重新开始以及菜单触发的事宜，清理掉没有雷的格子就须要利用“递归”的方法来使该功能可以大略的实现。

关键词：扫雷；Eclipse；事宜；递归

Design and Implementation of Mine Game

Mine the game has a long history, from the mine was developed to now numerous optimization, the game is becoming more and more let a person fondle admiringly, simple style with a nice game interface, every detail reflects the charm of mine. So I'm going to develop a minesweeper game.

The graduate design study was designed with the JAVA language as a development environment, using Eclipse to design and develop a game like Windows minesweeper to implement its basic functions. The paper firstly introduces the background of the project and analyzes the requirements and feasibility analysis. Then the game process was designed to introduce the random algorithm of how the thunder in the minefield was placed and produced. Finally introduced the game may trigger a variety of time, such as a mouse click on the clear time and there is no ray of diamonds, mouse events including click to or no click to ray trigger events and click to restart and menu trigger events, clearing out squares no ray will need to use the "recursive" methods to make the function can be simple to implement.

Key words: Mine game; Visual Basic 6.0; Affairs; Recursion

摘 要i

Abstractii

1绪论1

1.1课题背景及意义1

1.2开拓工具的选用及先容1

1.3选题目的和意义2

1.4本文紧张研究的内容2

2需求剖析3

2.1可行性剖析3

2.2扫雷游戏功能描述3

2.3扫雷游戏用例图4

2.4扫雷游戏功能需求4

2.5扫雷游戏界面需求5

2.6扫雷游戏功能模块6

3游戏的概要剖析与设计7

3.1设计构想7

3.2流程方案8

3.3界面方案9

3.4算法思想9

4游戏的详细设计11

4.1游戏初始化11

4.2雷区的支配12

4.3游戏中紧张模块的先容与利用13

4.3.1鼠标事宜13

4.3.2地雷及雷区表面探测情形14

4.3.3打消未靠近地雷的格子15

4.3.4游戏难度的选择16

4.3.5菜单栏的功能16

4.4游戏的判断16

4.4.1游戏成功完成16

4.4.2游戏失落败16

4.5类设计17

4.5.1MineGame类17

4.5.2Block类18

4.5.3BlockView类19

4.5.4Record类20

4.5.5ShowRecord类21

4.5.6MineArea类22

4.5.7LayMines类23

5游戏实现25

5.1游戏难度自定义25

5.2扫雷28

5.2.1玩家通过右键进行扫雷，并显示小红旗28

5.2.2玩家因触碰到雷而导致游戏结束29

5.2.3玩家扫雷成功29

5.2.4玩家游戏数据显示30

5.3程序打包发布过程32

6游戏测试结果33

6.1游戏难度自定义测试33

6.2扫雷测试35

6.3玩家游戏数据显示测试37

6.4游戏数据显示区测试39

6.5递归算法测试43

结 论44

参考文献45

致 谢47

外文原文48

中文翻译55

图2-1 扫雷游戏用例图从上述扫雷游戏功能描述以及用例图可以剖析出，全体扫雷游戏中，玩家所能进行的操作有：选择难度、开始游戏、重新开始游戏和记录查询等。

图3-2 整体方案图

②③⑤④⑥图3-3 方案样图解释如下：①：游戏主界面（Interface）。
②：菜单（Menu）。
③：地雷数显示区（MineNumberArea）④：重新开始（Restart）。
⑤：扫雷用时显示区(TimeArea)。
⑥：地雷区(MineArea)。

扫雷数据显示区地雷区图4-1 游戏初始界面游戏界面相对打算机自带的扫雷游戏比较简洁，紧张由游戏数据显示区域以及雷区构成。
我们利用ImageIcon工具来存放地雷的图标，可以图标大小最好要小一些，否则会在格子上显示不全。
对地雷区的初始化是很主要的，我们利用一个循环即可实现初始化。
玩家点开游戏之后可以点击菜单栏选择扫雷游戏的难度，不同的难度就代表了不同的地雷总数和尺寸，自定义的难度也会设置雷数和尺寸，设置的这些数据全部存放在几个变量之中，当雷区要初始化的时候程序会调用这么变量属性，然后通过一个循环来完成初始化。
紧张代码如下:

而之前所说的循环初始化实在便是循环的加载组件，雷区便是由一个个组件构成的，通过循环将所有的格子都支配到雷区，然后再随机产生地雷并支配到雷区上。
组件位置的摆放是按照其在数组中的位置来摆放的，所有的格子组件都存放在一个二维数组之中，组件在这个数组中的下标便是他在布局中的位置。
菜单栏是由菜单组件构成的，也便是JMenu组件，这个是菜单组件，用来定义未点击时的菜单样式，这个组件有可以设置JMenauItem组件，这是菜单项的意思，是当玩家点击了菜单后展示出来的子菜单栏。
扫雷游戏的计时区以及计数区又是利用另一种组件完成的，叫做JTextField，这个组件是文本显示的组件，在设置了不可的属性后，该组件在显示的外不雅观上会有变革，边框会变灰一些，意味着该组件不能够点击或者输入。
然后利用一个方法随着韶光动态的在韶光区以一秒为单位增加，计数区则会随着用户标记雷而减一，可以减到负数。
在设置界面的时候还须要进行一些设置，比如设置属性来让玩家在关闭游戏窗口时，系统会自动开释资源，并关闭窗口。

判断为左键且该格子为未探测状态：

支配地雷：

判断地雷该当被支配的位置：

游戏中紧张模块的先容与利用鼠标事宜我们通过点击鼠标左键或者鼠标右键来完成游戏，利用系统自带的MouseDown和MouseUp事宜来相应玩家的操作。
函数原型如下：组件名称：

组件名称：

这两个原型中的参数，Button参数值分别表示玩家用鼠标的左键或者右键进行点击的。
其意义如下：1：左键 2：右键如果同时按两个按键，那么系统就会传回3，由于点左键是1，点右键是2，一起点便是两个值相加了。
在本次的扫雷设计中，我们会用鼠标的MouseUp事宜来相应玩家的操作，个中鼠标左键用来点开玩家认为没有雷的格子，鼠标右键用来标记玩家认为下面藏有雷的格子。
利用MouseaUp事宜而不用MouseaDown事宜的缘故原由是，前者是在当鼠标按键抬起是触发，而后者是当按键按下就触发。
如果玩家在点击某一个格子的时候溘然创造彷佛点错了，此时玩家只要连续按下鼠标右键，再抬起的时候就会创造格子被标记成地雷了，现在的游戏一样平常都有这个功能，这可以有效的提升玩家的游戏体验。
在人机交互的界面上，鼠标的操作是很主要的，但是程序的设计不合理会使鼠标无法发挥应有的功能。
在鼠标点击事宜中利用MouseUp来相应事宜在上面也进行理解释，这样就可以很奥妙的让玩家体会到游戏的知心之处，可以有效的提升玩家的游戏体验。
当鼠标左键点击格子时：

当鼠标右击标识有雷的格子时：

地雷及雷区表面探测情形在雷区的设计上，我利用循环加载组件的方法让雷区布满格子，如果玩家点击了格子就会让该格子下面隐蔽的组件显示出来如图4-2和图4-3所示：

图4-2地雷随机天生

图4-3 地雷被标记玩家通过单击格子来点开格子，右击格子标记地雷。
由于利用了两个数组记录地雷的位置以及被点开的信息，以是可以通过两层嵌套循环来判断该格子周围雷的数目，而且系统会点开该格子周围8个格子中没有雷的格子，这又须要用到递归调用来一贯进行这个点开格子并验证的过程，直到不符合条件为止。
利用这种嵌套循环以及递归调用，都会使一个耗时耗力的问题变得随意马虎办理起来，使得代码构造也变得清晰明了，并且会提高系统的打算速率。

类设计MineGame类MineGame类紧张卖力开始游戏，菜单的设计，以及难度的转换。
展示该类的UML图如图4-4所示。

图4-4 MineGame类的类图（1）成员变量bar 是窗体的菜单栏变量。
fileMenu1 是扫雷游戏的菜单，叫做“游戏”。
fileMenu2 是扫雷的另一个菜单，叫做“帮助”。
低级 是扫雷游戏的难度变量。
中级 是扫雷游戏的难度变量。
高等 是扫雷游戏的难度变量。
扫雷榜 是扫雷的统计信息变量。
mineArea 是MineArea雷的工具，是设计雷区的变量。
file 是文件变量，用来读取扫雷记录。
hashtable 是用来临时存放扫雷记录。
showHeroRecord 是用来显示扫雷记录的变量。
（2）成员方法MiwneGaame（）通过该方法设置了游戏整体的位置和布局，并实现菜单栏功能，初始化统计信息。
actionPerformed(ActionEvent e)是相应点击菜单项的方法，通过该方法可以实现选择不同难度调度游戏的雷数和尺寸。
玩家点选不同的菜单项会让该方法实行不同的操作。
main()方法是游戏开始的方法，通过new了一个MineGame的工具来实现游戏的开始。

图4-5 Block类的类图

图4-6 BlockView类的类图

图4-7 Record类的类图

ShowRecord类是显示扫雷记录的类。
展示该类的UML图如图4-8所示。

图4-8 ShowRecord类的类图

ShowRecord() 方法是该类的布局方法，初始化成员变量。

readAndShow() 方法会把在文档中记录的玩家通关信息筛选出来（按游戏完成是花费的韶光最短为条件筛选），并显示到弹出的对话框中。

actionPerformed(ActionEvent e)方法是相应玩家操作的方法，当玩家想要显示游戏记录的时候系统会相应玩家的哀求并调用显示成绩的方法，在弹框中刷新成绩。

MineArea类紧张用于雷区的初始化以及鼠标事宜的相应。
展示该类的UML图如图4-9所示。

图4-9 MineArea类的类图

MineArea()方法是该类的布局方法，初始化组件和一下工具，设置字体颜色、边框颜色等，并调用初始化雷区的方法来初始化雷区。

initMineArea()方法用来设置雷数和游戏界面所有格子的数量，初始化雷区。

initMine()方法是真正实行初始化的方法。

setRow(int row)方法用来设置行数。

setColum(int colum)方法用来设置列数。

setMineCount(int mineCount)方法用来设置地雷总数。

setGrade(int grade)方法用来设置难度。

actionPerformed(ActionEvent)方法是相应鼠标点击格子的事宜的方法，当点击的格子下面没有雷，该方法会显示该格子周围雷的数目，有雷则显示雷的图标。

show()方法是显示格子内容，并且利用递归调用来显示周围格子的内容，直到这个格子周围有雷。

mousePressed(MouseEvent)方法相应玩家对格子进行的鼠标左键单击事宜和鼠标右键点击事宜。

inquireWin()方法是在玩家在游戏过程中知足得胜条件是触发的方法，同时会调用其他方法弹框提示玩家游戏结束。

LayMines是打算不是雷的格周围雷个数的类，以及设置点选之后的图片样式。
标明该类的UML图如图4-10所示。

图4-10 LayMines类的类图

ayMines() 布局方法，定义图片资源。

layMinesForBlock(Block block[][], int mineCount) 方法会判断是否是第一次点击格子，如果玩家是第一次点击格子，开始随机产生雷，但是雷不会支配到第一次点的格子上。
如果不是第一次点击且该格子没有雷时司帐算周围8个格子中有雷的数目并显示出来。

图5-1 选择难度以及游戏自定义

图5-2 低级难度

图5-3 中级难度

图5-4 高等难度

图5-5 自定义难度如图5-1所示，玩家可以自己选择游戏难度，个中有低级，中级，高等以及自定义四种难度，所对应的游戏界面的尺寸也不相同，以及地雷的总数也不相同，雷数越多则难度越大，同时玩家可以自定义游戏难度，通过输入行列数以及地雷数设置游戏界面的大小以及难度。
如图5-2、图5-3、图5-4、图5-5所示，分别展示了低级、中级、高等以及自定义难度的游戏界面尺寸和雷数。

图5-6 扫雷图玩家在游戏过程中会对某一格周围是否有雷进行判断，当玩家认为格子下有雷时就可以通过利用鼠标右键点击该格子，将该格子标识为小红旗如图5-6所示。

图5-7 扫雷失落败图如图5-7所示，当玩家在点开了有雷的格子时，游戏失落败，系统会自动将所有的地雷显示出来，并且会弹出一个窗口提示玩家:“你输了，请连续努力！
”。
除此以外还有两个选项，当玩家选择重新开始按钮时，游戏界面初始化，雷区中的雷全部取消，等待玩家第一次点击格子后开始布雷；如果用户点的是取消的话，就可以关掉这个提示的弹框。

图5-8 扫雷成功图如图5-8所示，当所有的地雷用都被玩家用小红旗标识出来，并且非雷的格子也被点开时游戏结束，计时停滞，系统弹框提醒玩家“您真厉害，请输入您的名字，记录上榜！
”，玩家可以在这个界面输入自己的名字来保存扫雷成绩。

图5-9扫雷榜图如图5-9所示，每当玩家成功扫完所有的雷后，系统会自动的记录本次的成绩，保存在本地的txt文档中，内容是三种难度，玩家姓名以及对应难度玩家所用的最少游戏韶光。
当玩家点击查看英雄榜的时候系统默认只显示三种难度和匿名。

图5-10 最佳成绩显示图

图5-11 重新记分显示图如图5-10所示，玩家点击关闭时此窗口会关掉这个弹窗，当点击重新记分时，统计信息会清空，点击显示成绩就好刷新并将历史最好的成绩显示出来。
界面也会发生变革，可以显示出游戏用时。

将清单文件保存到E:workspace扫雷bincomzxmine中，也便是和编写的扫雷游戏程序天生的字节码存放的位置相同，担保这些文件放在一个目录下。
须要把稳的是，清单文件中的所有内容均为键值对的形式存放，键值直接必须空一个空格。

预期结果

选择不同的难度后可以精确的初始化雷区

输入条件

分别点击低级、中级、高等和自定义

测试结果

点选不同难度后系统会自动改变雷区大小和地雷数

图6-1 游戏难度以及自定义测试

图6-2 低级难度测试

图6-3中级难度测试

图6-4 高等难度测试

图6-5 自定义难度测试如图6-1所示，本次扫雷游戏设计将游戏的难度设定为初、中、高以及自定义四种难度，前三种难度对应的游戏界面的尺寸以及地雷总数是不同的，难度越大雷数越多，尺寸也越大，玩家扫雷时就须要更加的动脑思考才能通关。
除了固定的难度以外还可以自定义难度，玩家须要自己输入尺寸与雷数，系统根据玩家的哀求生产新的游戏，难度可以更加的灵巧，这样可以让玩家更满意。
图6-2、图6-3、图6-4、图6-5测试了四种难度的选择，由图可以看出难度的选择功能正常，可以自由变换尺寸和地雷总数。

预期结果

成功的将所有地雷标记出来后，游戏可以立马结束且会弹框提示输入玩家名字

输入条件

将所有地雷标记并将非雷格子点开

测试结果

游戏结束并且显示了哀求玩家输入名字的弹框

扫雷失落败测试用例：表6-3 扫雷失落败测试用例表

预期结果

点击了有雷的格子后游戏可以立马结束且弹框提示玩家游戏失落败

输入条件

点击有雷的格子

测试结果

游戏精确的结束且弹框提示了游戏失落败的提示

图6-6 游戏完成并且扫雷成功测试如图6-6所示，玩家可以通过左键单击格子点开格子，右键单击标识地雷的办法完成游戏。
当玩家将所有的地雷都标识出来且其他的格子都被点开的情形下，游戏胜利。
系统会弹框提示玩家成功完成了游戏任务“您真厉害，请输入您的名字，记录上榜！
”。
玩家可以在弹出的弹框中输入自己的名字，若不输入则默认为匿名，然后系统会保存玩家的游戏记录。
当玩家点击扫雷榜的时候可以查看自己用时最短的游戏记录。

图6-7 游戏完成但是扫雷失落败测试如图6-7所示，玩家可以通过左键单击格子点开格子，右键单击标识地雷的办法完成游戏。
当玩家在进行扫雷游戏的时候，欠妥心点击了有雷的格子，这时候地雷被引爆了，所有未被标记的和已被标记的都被引爆，游戏结束。
此时系统会自动将所有的地雷显示出来，方便玩家查看之前标记的精确与否，可以总结履历。
然后系统弹框提示“你输了，请连续努力！
”，玩家可以点击重新开始的按钮重开游戏，连续寻衅扫雷游戏，也可以选择结束游戏。

预期结果

点击“最佳成绩”按钮时会显示玩家最佳的游戏记录

输入条件

打开游戏的扫雷榜，点击“最佳成绩”按钮

测试结果

游戏可以精确的显示玩家的游戏记录

重新记分测试用例：表6-5 重新记分测试用例表

预期结果

点击“重新记分”按钮时会打消玩家以往的游戏记录

输入条件

打开游戏的扫雷榜，点击“重新记分”按钮

测试结果

点击按钮后游戏记录消逝，再点击“最佳成绩”按钮只会显示默认的成绩

图6-8 扫雷榜测试

图6-9 最佳成绩测试

图6-10 重新记分测试如图6-8和图6-9所示，玩家在进行游戏时，如果成功的扫完雷，系统会提示并保存游戏记录。
在扫雷榜上玩家可以进行查看。
但是当玩家反复通关后，系统会自动的将用时最短的扫雷记录显示出来，以是玩家在查看记录的时候只能看到最快一次通关的记录。
通过图6-10可以看出，当玩家点击了“重新记分”按钮后，之前游戏记录都会被打消掉，只会显示默认的数据：韶光为999秒，名字是匿名。

预期结果

第一次点击雷区的格子时，计时区开始计时，游戏结束时计时停滞，重新开始游戏时，计时归零

输入条件

点击雷区的任意一格，然后结束游戏，末了点击“重新开始”按钮

测试结果

当点击雷区任意一格后计时开始，计时正常。
然后点击有雷的格子结束游戏创造计时停滞。
点击“重新开始”后计时区的计时精确归零

图6-11 开始计时测试

图6-12 计时停滞测试

图6-13 重新计时测试如图6-11，图6-12，图6-13所示，当点击雷区中的任意一格后，计时区开始正常计时。
当游戏结束时计时区的计时就会停滞，末了点击了“重新开始”后计时区的计时归零。
地雷数显示区测试用例：表6-7 地雷数显示区测试用例表

预期结果

标记地雷后计数区的数字会减1，如果标记数超过地雷数，计数区会用负数显示

输入条件

先标记一颗地雷，然后将所有的地雷标记出来

测试结果

标记一颗地雷后，计数区可以精确的减少1个，然后当所有的地雷全被标记后，如果连续标记，计数区可以精确的以负数表示

图6-14 计数区测试

图6-15 计数区负数显示测试如图6-14，图6-15所示，当标记了一颗地雷后计数区中的数字会相应的减少一个，表示有一颗雷被找到了。
但是如果标记数超过了地雷的数目，计数区会以负数显示，表示有的地雷标记错了。

递归调用测试用例：

表6-8 递归调用测试用例表

预期结果

当点击一个周围八个格子中都没有雷的格子时，系统会将这8个格子也点开

输入条件

点开一个周围没有雷的格子

测试结果

系统精确的将周围的八个格子点开，如果这些格子中周围的格子没有雷的话还会自动点开

图6-16 递归算法测试

如图6-16所示，当点击一个周围八个格子中都没有雷的格子时，系统会将周围的格子点开，被点开的格子也会显示周围的地雷数。
如果被点开的格子周围还是没有地雷，系统就会递归调用再把周围的格子点开。

扫雷游戏的代码编写完成，且基本功能也实现了，虽然与电脑上自带的扫雷游戏比较在界面上还是有着一些差距，一些小细节也没有完善，但已经让我很满意了，我会在往后连续完善这些细节，让这个扫雷游戏变得愈来愈好玩。
在大略的测试后，该游戏也达到了我的预期，以是本次的设计就到此结束了。

毕业设计对付我们来说并不是大略的一个毕业考察而已，这是我们的一个机会，一个将大学四年所学到的知识结合起来，通过自己的构思完成一个别系的机会。
在完成这个别系的过程中，一定会碰着许许多多的问题，这些问题就犹如大山挡在我们的面前，如何去办理这些问题也是我们要思考的。
而当我们把困难都办理掉，成功完成毕业设计的时候，就解释我们成功的摆脱了只会理论知识，不会办理实际问题的状态，磨炼了我们学习新事物并加以利用以及创造问题并找到方法去办理的能力。

虽然这次的扫雷游戏看似大略，但是个中却涉及了GUI设计，这一部分在学校是没有深讲的，须要我自己去学习。
个中有各种组件的调用，各种控件的利用等，我通过本次的毕业设计又学到了许多的新知识。

通过编写这次的扫雷游戏，我深刻的认识到了细节问题的主要性，这些问题看似无关紧要但是如果忽略会养成不好的编程习气，以是我们要着眼于细节，长于去创造身边的一些小事情，让自己的水平不断提高。
而且我的编程能力在不断的编写代码的过程中也有了显著的提高。
很多时候人们都认为知识学过了就行，但是当实际去用的时候就会创造这些知识是多么的陌生。
以是我认为学过的知识就要多用，用实际操作来让知识真正变成自己的。

[1] 耿祥义.Java大学实用教程[M].北京:清华大学出版社,2009.

[2] 冯锋,王运坚.Visual Basic 程序设计根本教程[M].西安：电子工业出版社，1999。

[3] 王鹏.JavaSwing图形界面开拓与案例详解[M].北京:清华大学出版社,2008。

[4] 李怀明.Visual Basic 6.0 中文版 参考详解[M].北京：清华大学出版社，1999。

[5] 丁振凡.Java措辞实验教程[M].北京:北京邮电大学出版社,2005。

[6] 郑莉.Java措辞程序设计[M].北京:清华大学出版社,2006。

[7] 伍俊良.VB课程设计与系统开拓案例[M].北京：清华大学出版社，2002。

[8] 孙全党,王吴迪,赵枫朝.Java程序设计运用教程[M].北京:电子工业出版社,2006。

[9] 雷之宇.Java项目开拓实践-网络篇[M].北京:中国铁道出版社,2005。

[10] 赵玉阳.Java从入门到精通[M].北京:清华大学出版社,2006。

[11] 何斌,刘醒.Visual Basic 6.0 运用指南[M].成都：四川大学出版社，1998。

[12] 毕广吉.Java程序设计实例教程[M].北京:冶金工业出版社，2007年。

[13] 李善茂.Visual Basic 6.0 高等编程技巧[M].西安：电子工业出版社，1999。

[14] 王保罗.Java面向工具程序设计[M].北京:清华大学出版社，2003年.公民邮电出版社，2004

[15] 刘腾红，孙细明.信息系统剖析与设计[M].北京:科学出版社，2003年。

[16] 林邦杰，彻底研究java[M].北京:电子工业出版社，2002年。

[17] 刘京华. Java Web整合开拓王者归来[M].北京:清华大学出版社，2010。

[18] 唐任仲.工程运用软件开拓技能[M].北京：化学工业出版社，1999。

[19] 谭浩强.Visual Basic 6.0 中文版 提高与运用[M].西安：电子工业出版社，1999。

[20] (美)阿诺德，Ken Arnold，等. Java程序设计措辞[M].北京:公民邮电出版社，2006.

[21] Bruce Eckel. Thinking in Java[M]. Upper Saddle River, New Jersey, USA: Prentice Hall, 2006.

[22] Holger Eichelberger,Klaus Schhmid.Flexible resource monitoring ofJava programs.[J].The Journal of Systems & Software,2014 Elsevier.

[23] Joshua Bloch. Effective Java[M]. Piscataway, N.J: IEEE Press, 2009.

[24] oug Twilleager,Jeff Kesselman,Athomas Goldberger,Daniel Petersen,Juan Carlos,Soto,Chris Melissinos.Java Technologies for games.[J].Computers in Entertainment(CIE),2004,Vol.2(2),pp.18-18 ACM.

感谢杰普基地的老师以及校内辅导老师，在这次我的毕业设计过程中，老师们对我的悉心的辅导，从一开始的开题报告与选择到后来的系统设计，从程序设计到论文的编写，他们纠正了我许多的不成熟的想法和考虑，给我提出了许多宝贵的建议，而且在程序设计与开拓过程中碰着的最困难的时候给予我连续努力完成设计的信心。
老师们严谨的作风和对我的严格哀求，使我战胜了

通过这次毕业设计的全体开拓过程，我系统开拓过程从需求剖析到详细功能实现，再到终极测试和掩护的理解有了很大的进步，让我对系统开拓有了更深层次的认识。
现在我的动手能力和独立办理问题的能力也得到了很大的磨炼和提高，这是这次毕业设计最好的收成。

末了，在全体系统开拓过程中，我身边的同学和朋友给了我很多的建议，让我很快的确定了系统的业务逻辑。
在次，我衷心的向他们表示感谢。

在论文完成过程中，本人还得到了其他老师和许多同学的热心帮助，本人向他们表示深深的谢意！

末了向在百忙之中评审本文的各位专家、老师表示衷心的感谢！

Thinking in Java

Learning Java

At about the same time that my first book, Using C++ (Osborne/McGraw-Hill, 1989), came out, I began teaching that language. Teaching programming ideas has become my profession; I’ve seen nodding heads, blank faces, and puzzled expressions in audiences all over the world

since 1987. As I began giving in-house training with smaller groups of people, I discovered something during the exercises. Even those people who were smiling and nodding were confused about many issues. I found out, by creating and chairing the C++ track at the Software Development Conference for a number of years (and later creating and chairing the Java track), that I and other speakers tended to give the typical audience too many topics too quickly. So eventually, through both variety in the audience level and the way that I presented the material, I would end up losing some portion of the audience. Maybe it’s asking too much, but because I am one of those people resistant to traditional lecturing (and for most people, I believe, such resistance results from boredom), I wanted to try to keep everyone up to speed. For a time, I was creating a number of different presentations in fairly short order. Thus, I ended up learning by experiment and iteration (a technique that also works well in program design). Eventually, I developed a course using everything I had learned from my teaching experience. My company, MindView, Inc., now gives this as the public and in-house Thinking in Java seminar; this is our main introductory seminar that provides the foundation for our more advanced seminars. You can find details at www.MindView.net. (The introductory seminar is also available as the Hands-On Java CD ROM. Information is available at the same Web site.)

The feedback that I get from each seminar helps me change and refocus the material until I think it works well as a teaching medium. But this book isn’t just seminar notes; I tried to pack as much information as I could within these pages, and structured it to draw you through into the next subject. More than anything, the book is designed to serve the solitary reader who is struggling with a new programming language.

The singly rooted hierarchy

One of the issues in OOP that has become especially prominent since the introduction of C++ is whether all classes should ultimately be inherited from a single base class. In Java (as with virtually all other OOP languages except for C++) the answer is yes, and the name of this ultimate base class is simply Object. It turns out that the benefits of the singly rooted hierarchy are many.

All objects in a singly rooted hierarchy have an interface in common, so they are all ultimately the same fundamental type. The alternative (provided by C++) is that you don’t know that everything is the same basic type. From a backward-compatibility standpoint this fits the model of C better and can be thought of as less restrictive, but when you want to do full-on objectoriented programming you must then build your own hierarchy to provide the same convenience that’s built into other OOP languages. And in any new class library you acquire, some other incompatible interface will be used. It requires effort (and possibly multiple inheritance) to work the new interface into your design. Is the extra “flexibility” of C++ worth it? If you need it—if you have a large investment in C—it’s quite valuable. If

you’re starting from scratch, other alternatives such as Java can often be more productive.

All objects in a singly rooted hierarchy can be guaranteed to have certain functionality. You know you can perform certain basic operations on every object in your system. All objects can easily be created on the heap, and argument passing is greatly simplified. A singly rooted hierarchy makes it much easier to implement a garbage collector, which is one of the fundamental improvements of Java over C++. And since information about the type of an object is guaranteed to be in all objects, you’ll never end up with an object whose type you cannot determine. This is especially important with system-level operations, such as exception handling, and to allow greater flexibility in programming.

Containers

In general, you don’t know how many objects you’re going to need to solve a particular problem, or how long they will last. You also don’t know how to store those objects. How can

you know how much space to create if that information isn’t known until run time?

The solution to most problems in object-oriented design seems flippant: You create another type of object. The new type of object that solves this particular problem holds references to other objects. Of course, you can do the same thing with an array, which is available in most

languages. But this new object, generally called a container (also called a collection, but the Java library uses that term in a different sense so this book will use “container”), will expand itself whenever necessary to accommodate everything you place inside it. So you don’t need to know how many objects you’re going to hold in a container. Just create a container object

and let it take care of the details.

Fortunately, a good OOP language comes with a set of containers as part of the package. In C++, it’s part of the Standard C++ Library and is often called the Standard Template Library(STL). Smalltalk has a very complete set of containers. Java also has numerous containers inits standard library. In some libraries, one or two generic containers is considered good enough for all needs, and in others (Java, for example) the library has different types of containers for different needs: several different kinds of List classes (to hold sequences), Maps (also known as associative arrays, to associate objects with other objects), Sets (to hold one of each type of object), and more components such as queues, trees, stacks, etc.

From a design standpoint, all you really want is a container that can be manipulated to solve your problem. If a single type of container satisfied all of your needs, there’d be no reason to have different kinds. There are two reasons that you need a choice of containers. First, containers provide different types of interfaces and external behavior. A stack has a different interface and behavior than a queue, which is different from a set or a list. One of these might provide a more flexible solution to your problem than the other. Second, different containers have different efficiencies for certain operations. For example, there are two basic types of List: ArrayList and LinkedList. Both are simple sequences that can have identical interfaces and external behaviors. But certain operations can have significantly different costs. Randomly accessing elements in an ArrayList is a constant-time operation; it takes the same amount of time regardless of the element you select. However, in a LinkedList it is expensive to move through the list to randomly select an element, and it takes longer to find an element that is farther down the list. On the other hand, if you want to insert an element in the middle of a sequence, it’s cheaper in a LinkedList than in an ArrayList. These and other

operations have different efficiencies depending on the underlying structure of the sequence. You might start building your program with a LinkedList and, when tuning for performance,change to an ArrayList. Because of the abstraction via the interface List, you can change from one to the other with minimal impact on your code.

Object creation & lifetime

One critical issue when working with objects is the way they are created and destroyed. Each object requires resources, most notably memory, in order to exist. When an object is no longer needed it must be cleaned up so that these resources are released for reuse. In simple programming situations the question of how an object is cleaned up doesn’t seem too challenging: You create the object, use it for as long as it’s needed, and then it should be destroyed. However, it’s not hard to encounter situations that are more complex.

Suppose, for example, you are designing a system to manage air traffic for an airport. (The same model might also work for managing crates in a warehouse, or a video rental system, or a kennel for boarding pets.) At first it seems simple: Make a container to hold airplanes, then create a new airplane and place it in the container for each airplane that enters the air-trafficcontrol zone. For cleanup, simply clean up the appropriate airplane object when a plane leaves the zone.

But perhaps you have some other system to record data about the planes; perhaps data that doesn’t require such immediate attention as the main controller function. Maybe it’s a record of the flight plans of all the small planes that leave the airport. So you have a second container of small planes, and whenever you create a plane object you also put it in this second container if it’s a small plane. Then some background process performs operations on the objects in this container during idle moments.

Now the problem is more difficult: How can you possibly know when to destroy the objects? When you’re done with the object, some other part of the system might not be. This same

problem can arise in a number of other situations, and in programming systems (such as C++) in which you must explicitly delete an object when you’re done with it this can become quite complex.

Where is the data for an object and how is the lifetime of the object controlled? C++ takes the approach that control of efficiency is the most important issue, so it gives the programmer a choice. For maximum runtime speed, the storage and lifetime can be determined while the program is being written, by placing the objects on the stack (these are sometimes called

automatic or scoped variables) or in the static storage area. This places a priority on the speed of storage allocation and release, and this control can be very valuable in some situations. However, you sacrifice flexibility because you must know the exact quantity, lifetime, and type of objects while you’re writing the program. If you are trying to solve a more general problem such as computer-aided design, warehouse management, or air-traffic control, this is too restrictive.

The second approach is to create objects dynamically in a pool of memory called the heap. In this approach, you don’t know until run time how many objects you need, what their lifetime is, or what their exact type is. Those are determined at the spur of the moment while the program is running. If you need a new object, you simply make it on the heap at the point that you need it. Because the storage is managed dynamically, at run time, the amount of time required to allocate storage on the heap can be noticeably longer than the time to create storage on the stack. Creating storage on the stack is often a single assembly instruction to move the stack pointer down and another to move it back up. The time to create heap storage depends on the design of the storage mechanism.

The dynamic approach makes the generally logical assumption that objects tend to be complicated, so the extra overhead of finding storage and releasing that storage will not have an important impact on the creation of an object. In addition, the greater flexibility is essential to solve the general programming problem.

Java uses dynamic memory allocation, exclusively. Every time you want to create an object, you use the new operator to build a dynamic instance of that object. There’s another issue, however, and that’s the lifetime of an object. With languages that allow objects to be created on the stack, the compiler determines how long the object lasts and can automatically destroy it. However, if you create it on the heap the compiler has no knowledge of its lifetime. In a language like C++, you must determine programmatically when to destroy the object, which can lead to memory leaks if you don’t do it correctly (and this is a common problem in C++

programs). Java provides a feature called a garbage collector that

automatically discovers when an object is no longer in use and destroys it. A garbage collector is much more convenient because it reduces the number of issues that you must track and the code you must write. More importantly, the garbage collector provides a much

higher level of insurance against the insidious problem of memory leaks, which has brought many a C++ project to its knees.

With Java, the garbage collector is designed to take care of the problem of releasing the memory (although this doesn’t include other aspects of cleaning up an object). The garbage collector “knows” when an object is no longer in use, and it then automatically releases the memory for that object. This, combined with the fact that all objects are inherited from the single root class Object and that you can create objects only one way—on the heap—makes

the process of programming in Java much simpler than programming in C++. You have far fewer decisions to make and hurdles to overcome.

Java编程思想

Java的学习

在我第一本书《Using C++》面市的险些同一韶光(Osborne/McGraw-Hill 于 1989 年出版)，我开始教授那种措辞。
程序设计措辞的教授已成为我的专业。
自 1989 年以来，我便在世界各地见过许多昏昏欲睡、满脸茫然以及困惑不解的脸庞。
开始在室内面向较少的一组人授课往后，我从作业中创造了一些特殊的问题。
纵然

那些上课面带会心的微笑或者频频点头的学生，对许多问题也存在认识上的稠浊。
在过去几年间的“软件开拓会议”上，由我主持 C++分组谈论会(现在变成了 Java 谈论会)。
有的演讲人试图在很短的韶光内向听众贯注灌注过多的主题。
以是到末了，只管听众的水平都还可以，而且供应的材料也很充足，但仍旧丢失了一部分

听众。
这可能是由于问得太多了，但由于我是那些采纳传统授课办法的人之一，以是很想使每个人都能跟上讲课进度。

有段韶光，我体例了大量传授教化简报。
经由不断的试验和修订(或称“反复”，这是在 Java 程序设计中非常有用的一项技能)，末了成功地在一门课程中集成了从我的传授教化履历中总结出来的所有东西——我在很长一段韶光里都在利用。
个中由一系列离散的、易于消化的小步骤组成，而且每个小课程结束后都有一些适当的练习。
我目前已在 Java 公开研讨会上公布了这一课程，大家可到 http://www.BruceEckel.com 理解详情(对研讨会的先容也以 CD-ROM 的形式供应，详细信息可在同样的 Web 站点找到)。
从每一次研讨会收到的反馈都帮助我修正及重新订定学习材料的重心，直到我末了认为它成为一个完善的传授教化载体为止。
但本书并非仅仅是一本教科书——我考试测验在个中装入尽可能多的信息，并按照主题进行了有序的分类。
无论如何，这本书的紧张宗旨是为那些独立学习的人士做事，他们正准备深入一门新的程序设计措辞，而没有太大的可能参加此类专业研讨会。

单根构造

在面向工具的程序设计中，由于 C++的引入而显得尤为突出的一个问题是:所有类终极是否都应从单独一个根本类继续。
在 Java 中(与其他险些所有 OOP 措辞一样)，对这个问题的答案(购买后显示)都是肯定的，而且这个终级根本类的名字很大略，便是一个“Object”。
这种“单根构造”具有许多方面的优点。

单根构造中的所有工具都有一个通用接口，以是它们终极都属于相同的类型。
另一种方案(就象 C++那样)是我们不能担保所有东西都属于相同的基本类型。
从向后兼容的角度看，这一方案可与 C 模型更好地合营，而且可以认为它的限定更少一些。
但假期我们想进行纯粹的面向工具编程，那么必须构建自己的构造，以期得到与内建到其他 OOP 措辞里的同样的便利。
需添加我们要用到的各种新类库，还要利用另一些不兼容的接口。
天经地义地，这也须要付出额外的精力使新接口与自己的设计方案合营(可能还须要多重继续)。
为得到 C++额外的“灵巧性”，付出这样的代价值得吗,当然，如果真的须要——如果早已是 C 专家，如果对 C有难舍的情结——那么就真的很值得。
但如果你是一名新手，首次打仗这类设计，象 Java 那样的更换方案大概会更省事一些。
单根构造中的所有工具(比如所有 Java 工具)都可以担保拥有一些特定的功能。
在自己的系统中，我们知道对每个工具都能进行一些基本操作。
一个单根构造，加上所有工具都在内存堆中创建，可以极大简化参数的通报(这在 C++里是一个繁芜的观点)。
利用单根构造，我们可以更方便地实现一个垃圾网络器。
与此有关的必要支持可安装于根本类中，而垃圾网络器可将适当的发给系统内的任何工具。
如果没有这种单根构造，而且系统通过一个句柄来操纵工具，那么实现垃圾网络器的路子会有很大的不同，而且会面临许多障碍。

由于运行期的类型信息肯定存在于所有工具中，以是永久不会碰着判断不出一个工具的类型的情形。
这对系统级的操作来说显得特殊主要，比如违例掌握;而且也能在程序设计时得到更大的灵巧性。
但大家也可能产生疑问，既然你把好处说得这么天花乱坠，为什么 C++没有采取单根构造呢,事实上，这是早期在效率与掌握上权衡的一种结果。
单根构造会带来程序设计上的一些限定。
而且更主要的是，它加大了新程序与原有代C码兼容的难度。
只管这些限定仅在特定的场合会真的造成问题，但为了得到最大的灵巧程度，C++终极决定放弃采取单根构造这一做法。
而 Java 不存在上述的问题，它是全新设计的一种措辞，不必

与现有的措辞保持所谓的“向后兼容”。
以是很自然地，与其他大多数面向工具的程序设计措辞一样，单根构造在 Java 的设计方案中很快就落实下来。

凑集与继续器

针对一个特定问题的办理，如果事先不知道须要多少个工具，或者它们的持续韶光有多长，那么也不知道如何保存那些工具。
既然如此，若何才能知道那些工具哀求多少空间呢,事先上根本无法提前知道，除非进入运行期。

在面向工具的设计中，大多数问题的办理办法彷佛都有些轻率——只是大略地创建另一种类型的工具。
用于办理特定问题的新型工具容纳了指向其他工具的句柄。
当然，也可以用数组来做同样的事情，那是大多数措辞都具有的一种功能。
但不能只看到这一点。
这种新工具常日叫作“凑集”(亦叫作一个“容器”，但 AWT

在不同的场合运用了这个术语，以是本书将一贯沿用“凑集”的称呼。
在须要的时候，凑集会自动扩充自己，以便适应我们在个中置入的任何东西。
以是我们事先不必知道要在一个凑集里容下多少东西。
只需创建一个凑集，往后的事情让它自己卖力好了。
幸运的是，设计优秀的 OOP 措辞都配套供应了一系列凑集。
在 C++中，它们因此“标准模板库”(STL)的形式供应的。
Object Pascal 用自己的“可视组件库”(VCL)供应凑集。
Smalltalk 供应了一套非常完全的凑集。
而 Java 也用自己的标准库供应了凑集。
在某些库中，一个常规凑集便可知足人们的大多数哀求;而在另一些库中(特殊是C++的库)，则面向不同的需求供应了不同类型的凑集。
例如，可以用一个矢量统一对所有元素的访问办法;一个链接列表则用于担保所有元素的插入统一。
以是我们能根据自己的须要选择适当的类型。
个中包括集、行列步队、散列表、树、堆栈等等。
所有凑集都供应了相应的读写功能。
将某样东西置入凑集时，采取的办法是十分明显的。
有一个叫作“推”(Push)、“添加”(Add)或其他类似名字的函数用于做这件事情。
但将数据从凑集中取出的时候，办法却并不总是那么明显。
如果是一个数组形式的实体，比如一个矢量(Vector)，那么大概能用索引运算符或函

数。
但在许多情形下，这样做每每会无功而返。
此外，单选定函数的功能是非常有限的。
如果想对凑集中的一系列元素进行操纵或比较，而不是仅仅面向一个，这时又该怎么办呢,

办法便是利用一个“连续器”(Iterator)，它属于一种工具，卖力选择凑集内元素，并把它们供应给继续器的用户。
作为一个类，它也供应了一级抽象。
利用这一级抽象，可将凑集细节与用于访问那个凑集的代码隔离开。
通过继续器的浸染，凑集被抽象成一个大略的序列。
继续器许可我们遍历那个序列，同时毋需关心根本构造是什么——换言之，不管它是一个矢量、一个链接列表、一个堆栈，还是其他什么东西。
这样一来，我们就可以灵巧地改变根本数据，不会对程序里的代码造成滋扰。
Java 最开始(在1.0和 1.1版中)供应的是一个标准继续器，名为 Enumeration(列举)，为它的所有凑集类供应做事。
Java 1.2 新增一个更繁芜的凑集库，个中包含了一个名为 Iterator 的继续器，可以做比老式的 Enumeration 更多的事情。

从设计角度出发，我们须要的是一个全功能的序列。
通过对它的操纵，该当能办理自己的问题。
如果一种类型的序列即可知足我们的所有哀求，那么完备没有必要再换用不同的类型。
有两方面的缘故原由匆匆使我们须要对凑集作出选择。
首先，凑集供应了不同的接口类型以及外部行为。
堆栈的接口与行为与行列步队的不同，而行列步队的接口与行为又与一个集(Set)或列表的不同。
利用这个特色，我们办理问题时便有更大的灵巧性。
其次，不同的凑集在进行特定操作时每每有不同的效率。
最好的例子便是矢量( Vector)和列表( List )的差异。
它们都属于大略的序列，拥有完备同等的接口和外部行为。
但在实行一些特定的任务时，须要的开销却是完备不同的。
对矢量内的元素进行的随机访问(存取)是一种常时操作;无论我们选择的选择是什么，须要的韶光量都是相同的。
但在一个链接列表中，若想到处移动，并随机挑选一个元素，就需付出“惨重”的代价。
而且假设某个元素位于列表较远的地方，找到它所需的韶光也会长许多。
但在另一方面，如果想在序列中部插入一个元素，用列表就比用矢量划算得多。
这些以及其他操作都有不同的实行效率，详细取决于序列的根本构造是什么。
在设计阶段，我们可以先从一个列表开始。
末了调度性能的时候，再根据情形把它换成矢量。
由于抽象是通过继续器进行的，以是能在两者方便地切换，对代码的影响则显得微不足道。
末了，记住凑集只是一个用来放置工具的储藏所。
如果那个储藏所能知足我们的所有须要，就完备没必要关心它详细是如何实现的(这是大多数类型工具的一个基本观点)。
如果在一个编程环境中事情，它由于其他成分(比如在 Windows 下运行，或者由垃圾网络器带来了开销)产生了内在的开销，那么矢量和链接列表之间在系统开销上的差异就或许不是一个大问题。
我们可能只须要一种类型的序列。
乃至可以想象有一个“完美”的凑集抽象，它能根据自己的利用办法自动改变基层的实现办法。

工具的创建和存在韶光

每个工具都哀求资源才能“生存”，个中最令人瞩目的资源是内存。
如果不再须要利用一个工具，就必须将其打消，以便开释这些资源，以便其他工具利用。
如果要办理的是非常大略的问题，如何打消工具这个问题并不显得很突出:我们创建工具，在须要的时候调用它，然后将其打消或者“毁坏”。
但在另一方面，我们平时碰着的问题每每要比这繁芜得多。

举个例子来说，假设我们要设计一套系统，用它管理一个机场的空中交通(同样的模型也可能适于管理一个仓库的货柜、或者一套影带出租系统、或者宠物店的宠物房。
这初看彷佛十分大略:布局一个凑集用来容纳飞机，然后创建一架新飞机，将其置入凑集。

对进入空中交通牵制区的所有飞机都如此处理。
至于打消，在一架飞机离开这个区域的时候把它大略地删去即可。

但事情并没有这么大略，可能还须要另一套系统来记录与飞机有关的数据。
当然，和掌握器的紧张功能不同，这些数据的主要性可能一开始并不显露出来。
例如，这条记录反响的可能是离开机场的所有小飞机的翱翔操持。
以是我们得到了由小飞机组成的另一个凑集。
一旦创建了一个飞机工具，如果它是一架小飞机，那

么也必须把它置入这个凑集。
然后在系统空闲期间，需对这个凑集中的工具进行一些后台处理。

问题现在显得更繁芜了:如何才能知道什么韶光删除工具呢,用完工具后，系统的其他某些部分可能仍旧要发挥浸染。
同样的问题也会在其他大量场合涌现，而且在程序设计系统中(如 C++)，在用完一个工具之后必须明确地将其删除，以是问题会变得非常繁芜。

最主要的问题之一是工具的创建及毁坏办法。
工具须要的数据位于哪儿，如何掌握工具的“存在韶光”呢,针对这个问题，办理的方案是互异其趣的。
C++认为程序的实行效率是最主要的一个问题，以是它许可程序员作出选择。
为得到最快的运行速率，存储以及存在韶光可在编写程序时决定，只需将工具放置在堆栈(有时也叫作自动或定域变量)或者静态存储区域即可。
这样便为存储空间的分配和开释供应了一个优先级。
某些情形下，这种优先级的掌握是非常有代价的。
然而，我们同时也捐躯了灵巧性，由于在编写程序时，必须知道工具的准确的数量、存在韶光、以及类型。
如果要办理的是一个较常规的问题，如打算机赞助设计、仓储管理或者空中交通掌握，这一方法就显得太局限了。
第二个方法是在一个内存池中动态创建工具，该内存池亦叫“堆”或者“内存堆”。
若采取这种办法，除非进入运行期，否则根本不知道到底须要多少个工具，也不知道它们的存在韶光有多长，以及准确的类型是什么。
这些参数都在程序正式运行时才决定的。
若需一个新工具，只需在须要它的时候在内存堆里大略地创建

它即可。
由于存储空间的管理是运行期间动态进行的，以是在内存堆里分配存储空间的韶光比在堆栈里创建的韶光长得多(在堆栈里创建存储空间一样平常只须要一个大略的指令，将堆栈指针向下或向下移动即可)。
由于动态创建方法使工具本来就方向于繁芜，以是查找存储空间以及开释它所需的额外开销不会为工具的创建造成明显的影响。
除此以外，更大的灵巧性对付常规编程问题的办理是至关主要的。

动态方法使该工具对付的一样平常逻辑的假设每每是繁芜的，以是找到存储和开释该内存的额外空间不会对创建工具产生主要的影响。
此外，更多的灵巧性对付办理一样平常的方案问题是至关主要的。

Java 工具不具备与主类型一样的存在韶光。
对付用 new 创建的工具，只要我们乐意，它们就会一贯保留下去。
这个编程问题在 C和 C++里特殊突出。
看来在 C++里碰着的麻烦最大:由于不能从措辞得到任何帮助，以是在须要工具的时候，根本无法确定它们是否可用。
而且更麻烦的是，在 C++里，一旦事情完成，必须担保将工具打消。
这样便带来了一个有趣的问题。
如果 Java 让工具依然故我，若何才能防止它们大量充斥内存，并终极造成程序的“凝固”呢。
在 C++里，这个问题最令程序员头痛。
但 Java 往后，情形却发生了改不雅观。
Java 有一个特殊的“垃圾网络器”，它会查找用 new 创建的所有工具，并辨别个中哪些不再被引用。
随后，它会自动开释由那些闲置工具霸占的内存，以便能由新工具利用。
这意味着我们根本不必操心内存的回收问题。
只需大略地创建工具，一旦不再须要它们，它们就会自动拜别。
这样做可防止在 C++里很常见的一个编程问题:由于程序员忘却开释内存造成的“内存溢出”。

在 Java 中，垃圾网络器在设计时已考虑到了内存的开释问题(只管这并不包括打消一个工具涉及到的其他方面)。
垃圾网络器“知道”一个工具在什么时候不再利用，然后会自动开释那个工具霸占的内存空间。
采取这种办法，其余加上所有工具都从单个根类 Object 继续的事实，而且由于我们只能在内存堆中以一种办法创建工具，以是 Java 的编程要比 C++的编程大略得多。
我们只须要作出少量的决议，即可战胜原来存在的大量障碍。