Java开发网 - 极端软件制程的Java工具

Java开发网

您没有登录

» Java开发网 » Design Pattern & UML

打印话题 寄给朋友 订阅主题

作者

极端软件制程的Java工具

chaos

We Are the World !!

发贴: 92
积分: 40

于 2003-04-17 20:21

==转贴自www.dotspace.idv.tw mailing list ==

好书推荐＞极端软件制程的Java工具--精通开放程序代码工具：
Ant、JUnit及Cactus

图文并茂版
http://www.javatwo.net/javaweek/history/javaweek20030417.pdf

前言
------
这是一本介绍如何使用工具协助Java应用程序开发的书籍。然而要
提升应用程序开发的效率，不仅仅是依赖工具而已，重要的是你的
开发程序（或称方法论）。也就是说，开发工具与开发程序的方法
论是相辅相成的。徒有方法论没有工具有时很难落实方法论的要求
，而仅仅依靠供工具，没有依循一定的方法论，工具的效能往往也
是有限的。因此读者拿到本书，可能会对书名中的『极端软件制程
(eXtreme Programming简称XP)』感到疑惑。其实『极端软件制程』
就是所谓的开发程序方法论。

XP是由Kent Beck于1995年创始的。是一种所谓的『轻量型(lightweight)』
或『灵活型(agile)』的方法论。XP是一个极端有纪律的方法论，他是
以程序编写为中心。作法是持续的查核程序代码，频繁的测试，重视客
户的参与，迅速的回馈。不断的重整及精炼其架构。持续性的整合，
以便在开发过程早期发掘问题。不断的设计及重设计，以及持续的规
划。希望针对应用程序开发过程中，对不断的需求变动可以有效的因
应。而其思维是依据四个价值为主：沟通、简化、回馈及勇气。从而
订定12项简单的实务作法(practice) [注1]。其中『持续性整合』、『自
动测试』这两个实务作法则有赖工具的辅助，才能有效的实施。（另
一个是重整(refactoring)，但目前其工具尚在发展中，并未列入本书的
范围。）其中本书所列的工具中，Ant是用来建构、持续性整合及部
署应用程序（尤其是J2EE的应用程序）。JUnit是用来执行单元测试。
Cactus是用来测试容器(container)服务器。HttpUnit是用来实作功能测试
。JMeter可以量测应用程序的执行效率。JUnitPerf则实作负荷测试。
而且这些工具几乎都是可以免费下载的开放程序代码软件。对于使用
者而言可以免除经济上的负担。除此之外，这些工具都是以Java撰写
而成的，对于撰写Java应用程序的开发团队，也可以很容易将这些工
具导入你的开发环境之中。

前面提到方法论与工具是相辅相成的，如果你不是使用XP，而是使
用其它的方法论，甚或你没有采用任何的方法论，是否可以使用这
些工具？答案是肯定的，因为这些工具原本就不属于任何方法论的
，只是本书认为这些工具非常适合XP，而特别将之收集，提供采用
XP的团队应用。但对于非XP的使用者而言，你也可以适度在你的工
作中引入这些工具，以辅助你的应用系统开发工作。此外本书使用
大量的范例，说明如何使用这些工具。并且在书后列出各种工具的
API参照，方便你操作这些工具。

使用Ant于持续性整合
-------------------------------
在这些工具中，Ant(Another Neat Tool)是一套重量型的工具，所谓重
量型的工具并不意味着它很复杂。相反的，它是一套功能强大，但
很容易使用的工具。尤其是对于开发J2EE应用程序的开发团队而言
，部署应用程序是一件非常困扰的工作，尤其是如果你像XP一样，
频繁的整合、测试及部署应用程序，没有一套整合的工具，这几乎
是一项不可能的任务。其次，Ant与各种IDE兼容，Ant并不取代IDE
，同样的IDE也不取代Ant。IDE可以大大的简化Java开发工作，但没
有办法在一个复杂的项目中，将建构及部署程序自动化。每一个软
体需要可重复的建构系统，而IDE并没有办法提供这样的系统。开
发人员对于IDE各有偏好。如Borland JBuilder、NetBeans、Forte CE、
Visual Age for Java、JDE及Ultra Edit。Ant在建构及部署程序上，提供
这些IDE一个标准，大大的降低混乱的情况。我们可以说Ant是一个
建构（build）工具，使得你的建构程序可以自动化。Ant的设计是特
别用来开发Java应用程序的。Ant是以Java撰写而成，所以是跨平台
，同时不依赖特定shell[注2]的指令，因为不同的操作系统的功能及
用法都不一样。相反的，Ant依赖Java平台，执行档案存取、编译，
及当你建构你的Java应用系统时所需的其它作业。

在建构及部署的循环过程应该都是自动化的，以避免你在操作时导
致错误。撰写一个建构脚本，同时也就是撰写建构程序的文件。当
有开发人员离职时，文件是相当重要的。使用Ant，你的公司可以保
存部署系统所需要的知识，因为这个建构及部署的程序，是保留在
Ant脚本（称作建构档（buildfile））中，并且可以自动执行。同时也
不会被绑在过去开发人员的IDE上（那是在个别开发环境上的设定）
。另一个Ant的优点，脚本非常有效的执行建构及部署的程序，同时
也将程序文件化。不像多数IDE的二位project组态文件，Ant建构档是
人人可以阅读的文字文件。

开发人员常常讨论到自动开发及测试，但鲜有人真正的实施。Ant使
得自动建构及测试变为可能。Ant及JUnit结合，可以允许开发团队，
每一天建构及测试他们的软件好几次。这样的自动化程序是值得尝
试的。你会在你忘了是谁破坏了系统之前，很快的找到凶手。你会
在整合性的臭虫，变得难以发觉之前找出它们。事实上Ant已经成为
Java自动建构的标准。

Ant是以建构脚本(script)的方式，订定建构的程序。Ant的建构脚本的
建构档，是以XML撰写而成。每一个建构文件包含一个project元素。一
个project元素包含一些targets元素。每一个target包含一组 tasks元素。
一个task执行一个功能，（如复制一个档案，编译一个project或建立
一个JAR档案）。一个target是tasks及properties（如定义输出档案的目
录等）的集合。一个target可以依赖于其它的targets，亦即这个target的
执行，必须等到其依赖的targets执行后才执行（例如，当你要编译之
前，你必须将档案转成JAR檔。）。这样你便可以依据你的需要，订
定各项建构工作的执行顺序。你可以定义任何你喜欢的targets，但Ant
有组标准的命名协议。透过定义这些元素（要执行的工作），你便可
以将建构作业自动化。

对于简单的项目这似乎是杀鸡用牛刀，但想想如果你的项目使用了
50个组件会如何？每一个组件都有其本身的部署描述及组态档，每
一个组件都部署在不同的容器中。在管理应用程序的复杂性，这种
方式变得非常重要了。同时这种技术也提供组件再使用的方便性。

此处要特别强调XP主张的持续性整合。在一般的项目中，程序设计
师往往等到期限将届才将各人的程序整合起来。这种作法，一旦碰
到整合性问题时，往往来不及处理。因为整合性的问题牵涉到各人
的程序代码，加上整合后的程序代码范围比各人的范围广且复杂，因此
很难找到问题所在。因此XP强调程序代码必须随时整合，及早发现问
题，而且是在问题单纯的时候就处理，才能事半功倍。因此XP强烈
要求每天至少要整合一次，并执行测试，以便发掘问题的所在。特
别是当你开发的是网络上的程序（牵涉到部署J2EE组件的问题），
整合工作非常麻烦，如果没有自动整合的工具，要每日整合应用程
式确实是程序设计师的梦魇。没有工具的辅助，自然没有人愿意这
么做。因此Ant在此发挥了极大的效能。

使用JUnit实作单元测试
---------------------------------
本书除了Ant以外，其余的工具都是测试的工具。诚然，要完整的测
试，以及让程序代码都没有臭虫，是不可能的。但是测试的用心可以
降低大部分程序代码的错误，可以维持程序一定程度的品质。因此测
试必须是有规律的实施，才能达到测试的效果。测试有许多种：包
括单元测试(unit test)、整合测试（integration tests）、功能测试
（functional tests）；及一些其它的辅助测试（auxiliary tests）（如效率
测试（performance tests）及回归测试（regression tests）等等）。JUnit
是用来实施单元测试之用，其余的测试采用的工具在本书中都有相
对的工具。JUnit可以结合其它的测试工具（当然也可以在Ant中执行
JUnit。）

一般程序设计师多不愿作测试，或者仅以简单的测试带过。他们的
借口一般是没有时间，其实更重要的是，没有好的方法。好的方法
不仅可以减少做测试的时间，更能提升测试的效率。因此为了让程
式设计师乐于作测试，更能提升测试的效能。在XP中特别规划作测
试的方法，同时由XP的创始人Kent Beck开发出一套单元测试的工具
JUnit[注3]。

JUnit是一套测试框架，可以很方便的整合到你的IDE开发工具之中
（如Borland的JBuilder已是内定整合了，或者你只要简单的
import junit.framework.*这个包裹即可）。一个单元测试，一般会检验
类别公开接口的所有方法。好的单元测试，无须测试类别所有行为
的排列组合，也不用测试极为简单的方法（如存取方法（Accessors）
；Get及Set方法）。使用JUnit你必须撰写测试案例(test case)。测试案
例就是测试你的类别中的公开方法，执行结果是否是预期的。测试
案例中可以内含一些测试资料及预期的测试结果，并执行这个被测
试的方法，然后评估执行的结果是否是预期的。这些测试案例可以
进一步整合成测试系列(test suite)，而测试系列也可以更进一步合并
成一个更大的测试系列。这种作法有个好处，就是你随时可以一个
指令便执行所有的测试。只要你对系统作了修改，你想知道，你的
修改是否对系统的其它部分产生了不当的影响，你便可以一次执行
所有的测试，这也就是所谓的回归测试。这样你随时可以对你的程
式很有信心。尤其是在XP中非常强调的重整，重整是变动你的程序
码，但不变动其应有的功能，以改善你的系统设计。因为重整会对
程序代码作许多变动，如移动方法、变更名称等等，如果没有单元测
试的保护，很可能重整便会破坏你的系统。

JUnit最大的优点是可以自动化的执行测试，你随时可以以一个指令
执行你想要的测试。这对程序设计师而言，大大的降低测试的困扰
。JUnit除了提供一个有规律的测试环境之外，XP更将单元测试提升
到设计的层次。所谓的先写测试(test first)，把测试当作一种协助实
作的指引。也就是在撰写你的程序代码之前先写测试，先写测试可以
让程序设计师更深入了解需求，并从而思索如何设计架构。

使用Cactus测试容器服务器
Cactus[注4]是用来测试容器中（in-container）的服务，也就是说「如
何在servlets及其它J2EE组件中实作单元测试[注5]？」为什么你需要
像Cactus这样一种框架来测试J2EE程序代码？这是因为J2EE中的成员
（如servlets、JSPs、EJBs等等）之间有着特定的关系，这些成员都
是在容器中执行。本质上，单元测试着眼的是程序代码的单元。但是
所有的J2EE程序代码无法凭空存在的，既使是最小的程序都要依赖其
他的程序代码单元（举例来说，Java程序都是要依赖JVM）。单元测
试最大的挑战就是，如何将单元从其背景区隔出来，以便独立的验
证（assert）其执行结果。

Cactus是一个开放程序代码框架，它提供Servlets、JSP客制卷标（custom
tags）及Servlet Filters在容器内的测试服务。其它的容器组件，如
connection pools、EJBs及JSPs使用Cactus可以很容易的作测试。撰写
Cactus测试案例完全是的扩充(extend)Cactus基础类别AbstructTestCase
（继承自JUnit的TestCase），并使用Cactus所提供的对象redirectors，
这个对象就像是一个指针指向容器的入口（entry）。这些redirectors
执行容器中为Cactus所撰写的测试案例（撰写的方式与JUnit的测试
案例相同，因为是继承自JUnit的TestCAse），并提供容器对象的存
取，如HttpServletRequest、PageContext及FilterChain。其中每一个都有
一个API直接支持的代理（proxy）：一个属于servlets，一个属于filters
，另一个属于客制卷标。未来还有更多。开发人员如果想要使用间
接支持的组件，可以选择任何其它适合的redirectors（一般是
ServletRedirector）来存取容器。此外，关于提供容器一个入口，并
存取特定的对象。Cactus与JUnit框架的整合，让使用者可以看到与
redirectors的谈论事项（business of talking）（两者几乎是透通的）。

为了在Web服务器中建构适当的对象，Cactus需要重复HTTP沟通的
请求-响应周期。要实现这个作法（同时也能允许查证Web服务器传
回的响应），Cactus测试案例在两个实例对象中完全执行，使得其
中这两个对象的动作看起来好象是一个—一个是在客户端，一个是
在伺服端。这个框架的作者做这样的决定，是为了简化测试案例的
建立：另一种方式是分别在客户端及伺服端各有一个。这种程序的
操作相当平稳，因为Cactus的测试案例是标准的JUnit测试案例。偶而
，执行测试会产生意外的行为，因为，既使是两个对象操作起来像
是一个，这两个对象并未共享相同的状态。不管如何，只要你小心
，并且对Cactus的架构了然于心，撰写执行于在容器中的测试是很
轻松的工作。

使用HttpUnit实作功能测试
-------------------------------------
HttpUnit主要是作为功能测试，或黑箱测试之用。Web应用程序使用
HttpUnit测试的，不是测试程序代码的『片段』，而是对Web服务作外
部查询，并检测所接收到的响应是否是预期的结果。XP强调功能测
试是为（而大部分是『由』）客户所撰写，以便从客户获得关于系
统状态高阶的回馈。因为功能测试检核的是整个系统，只有功能测
试才能抓到接近产品环境下，隐藏于其中的微妙臭虫（服务器环境
的问题、次系统互动的臭虫等等）。当一个系统达到成熟阶段（以
XP的说法，也就是一个项目的状态达到可以部署的状态），此时比
较可能（且需要），投入时间检测系统是否是按照期望的执行。自
动的功能测试可以抒解一些人（甚至是开发人员）严酷的重责；即
在发行新的建构时，以人工检测网页中未改变的部分。HttpUnit可以
与JUnitPerf的decorator结合，以提供快速的负荷测试（load-test）。除
此之外，因为HttpUnit是使用Java撰写而成，它们可以以任何你可想
像的方式架构。Web网页的传统测试案例所包含的测试如：在画面
中输入资料时，可能有许多错误的操作方式。在每一画面中检核使
用者使用这个画面的权限，然后是检核其输入的资料是否正确的，
最后检核适当的后续画面是否显示。使用Java程序代码执行这些测试
可能是一种累赘，因为这种作法大部分要重复一些微小的变动（哪
一个画面的字段要填写、哪一个错误讯息要传回等等）。理想上，
测试应用程序应该是在HttpUnit的上层开发，以处理这样的一些议题。

HttpUnit的功能可分为两大类：一是Web的客户端可以维护的状态，
及提供送出请求与取得响应的能力。其次是各式各样，可以简化检
核响应内容的方法。第一类的功能是可以与Web服务器交谈并且很
容易表达。第二类的功能是可以在个别的网页上实施单元测试。这
两个功能结合在一起，可以查核像网页流程这样的复杂行为。

HttpUnit的WebClient类别，可以充分的代表Web客户端的一个模型。
（实际上WebClient是一个抽象（abstract）类别，WebConversation是提
供开发人员使用的实作。）WebClient/WebConversation的行为就像是
一个标准的Web浏览器（browser）：它维护客户端的状态—包括持
续性响应表头（persistent response headers），cookies、相关的URLs、
及框架设定—并且允许使用者请求特定的资源并取得响应。与
WebConversation合作的是WebRequest及WebResponse。WebRequest代表
向远程服务器的一个请求，而WebResponse封装其响应。这些类别的
使用都非常简单。

请求及取得网页是非常重要的—但你如何使用HttpUnit，检核这些回
应是否是依照一定的顺序。在WebResponse对象中有许多的方法，可
以用来让你很简单的检测这些响应。其执行的顺序是：从源头（使
用response.getText()以文字的方式传回响应），到具体的特性（使用
response.getTableWithSummary()找到一个表格），最后是有用的结果
（使用response.getDOM()为HTML网页取得XML DOM[注6]）。这些
方法的结果可以用来与JUnit的验证结合，用来检查被请求的网页是
否是预期的。

HttpUnit提供弹性的Java API，以便在维护客户端的状态时，与Web
服务器互动。同时也提供一组功能强大的公用程序，使撰写HTTP
响应的验证更容易。

使用JMeter量测应用程序效率
------------------------------------------
理想上，在项目设计阶段，你会接收到一些重要的效率（performance）
标准要求。如必须支持多少个使用者同时上线，及这个系统会在怎样
的硬件上执行等。当然我们的环境没有办法都是那么理想的，但是你
开发的系统还是需要符合这些标准。所以不要等到项目后期才开始量
测系统效率。

JMeter是由Apache Software Foundation所开发，是一个100％纯Java的应用
程序。它是用来做负荷测试（load-test），及量测系统执行效率的工具
。它原本着重在Web应用程序，但目前它还是做成可扩充的。因此JMeter
可以执行HTTP、FTP、及RDBMS（支持Java Database connectivity（JDBC））
的负荷及效能测试。同时，你也可以撰写可执行测试的可插接（pluggable）
取样器（samplers）、可插接的timer，及资料分析与可视化的插件
（plugins）
。例如，你可以透过撰写你自己的客制取样器，来撰写一个测试Enterprise
JavaBeans（EJBs）、Simple Object Access Protocol（SOAP）、或Common
Object Request Broker Architecture（CORBA）的插件。

你可以使用JMeter仿真系统、服务器及网络连接的负荷状态。JMeter有
完整的多执行绪框架，可以使用多个执行绪并进行取样，以及使用独
立的ThreadGroups仿真不同功能的取样。因此你可以使用JMeter测试系统
在不同负荷型态下的执行效率，如大量的更新、大量的浏览、大量的交
易及在不同的负荷组合的仿真。使用JMeter的优点是，你可以透过图形
接口获得回馈，持续看到系统执行效率的变化。因为JMeter可以在使用
HTTP的网站实作负荷测试，他可以用来测试静态及动态资源的执行效
率：如档案、Java Servlets、Perl CGI、Python CGI、PHP、JavaServer
Pages
（JSP）、Cold Fusion、Active Server Pages等等。

使用JMeter你必须先建构，然后执行一个TestPlan。TestPlan中包含一到
多个ThreadGroups。你可以想象一个执行绪代表一个仿真的使用者，而
一个ThreadGroup是一组仿真的使用者。一般的规则是，你加入愈多的
执行绪，你的系统资源愈吃紧。一旦你在TestPlan中建立了所有的元素
（elements），你便可以开始执行你的测试。JMeter会编译你的测试元
素，并建构成单一的TestPlan对象。透过TestPlan，会形成一个JMeterEngine
。JMeterEngine建立执行绪，而每一个执行绪在测试案例中反复执行。
此外你必须加入一个timer，以仿真使用者（执行绪）的速度，这样的
行为才像真实世界的使用者所为。JMeter有三种timers：constant timer、
Gaussian random timer及uniform random timer。我们一般使用constant
timer
建立可重复的测试，而我们使用Gaussian random timer仿真真实世界的
使用者。另一个一般你会在ThreadGroup中加入的元素是controller。
JMeter使用两种类型的controller：testing及logic。当你的系统有多种不
同的通讯协议时（JDBS、HTTP、FTP等等），则使用testing controller。
testing controller会做取样，但不记录结果—因此你必须加入其它的东西
。logical controller则控制流程。它可以控制sub-controllers的反复行为。
一般你也会将一个listener加入ThreadGroup中。listener接收取样资料，
然后利用这些资料绘制图形或储存起来。JMeter使用两种型态的
listeners：visualizers及reporters。这两种listeners会将资料储存到档案
中
，或以图表显示。

你可以透过JMeter在网页中取得（get）或发送（post）资料。你也可以
传送HTML参数，以仿真画面的数据输入。因为JMeter很容易测试应用
系统的执行效率。你不用像其它的开发人员一样—你不用等待整个专
案完成才来测试其执行效率。你可以渐进式的建构系统的追踪器（tracer
bullets），然后评量这个追踪器的执行效率。你可以在你的系统变得
过份复杂之前，找出执行效率的主要瓶颈点。

使用JUnitPerf实作负荷测试
--------------------------------------
在项目规划的阶段，对于新系统的执行效率，都会有一定的要求标准。
你可以使用JUnitPerf来修饰你现有JUnit的测试案例，可以确保系统符合
执行效率的要求。如果你在某一部份的程序代码，有特定的执行效率需求
，你可以建立一个JUnitPerf测试，检验你的程序代码是否符合要求。以及
在你重整这些程序代码之后，是否仍符合执行效率的要求。例如，你可以
测试每一个Web网页，在1000人同时上线时，是否都可以在10秒内加载
，或平均加载时间低于5秒。

JUnitPerf 1.4版需要用到JUnit 3.2或更高的版本。JUnitPerf之中包含一组测
试decorators[注7]，及扩充自JUnit API的相关类别。也就是说，JUnitPerf测
试使用修饰者样式（pattern）扩充JUnit测试。因此在使用JUnitPerf之前，
你必须先有JUnit的测试。JUnitPerf可以让你很容易的加载测试，进行测
试的时候，如果程序未在一定的时间内响应，则会产生一个失败。

你也可以将JUnitPerf合并HttpUnit及JMeter测试Web网站的负荷。例如，撰
写一组JUnit测试，其中使用HttpUnit测试仿真一个使用者，在一个Web目
录中巡航（navigating）搜寻一个产品。同时在你使用JUnitPerf做时间测试
（timed test），并在执行巡航测试的时候，使用JMeter在网站中产生大量
的请求。当在15秒内未能巡航网站，找到预定的产品网页的时候，产生
一个失败。

JUnitPerf中有两种主要的测试种类：时间（timed）测试及负荷（load）测
试，这分别由TimedTest及LoadTest两个类别所定义。当你建立一个TimedTest
测试的decorator，你传给它的参数是一个已经存在的JUnit测试及可允许的
最大响应时间（毫秒）。TimedTest是一个JUnit的TestDecorator，TimedTest
会在超过指定的时间后，让被修饰的（decorated）测试产生一个失败。使
用TimedTest有两种方式：等待测试完成，然后检查使用的时间；或者只
要超过最大允许时间便立即产生一个失败。LoadTest也是一个测试decorator
，它的测试，是仿真一些使用者重复执行一些动作。你可以慢慢累加负
荷，或一次达到最大负荷的状态。

结语
------
本文对《极端软件制程的Java工具--精通开放程序代码工具：Ant、JUnit及
Cactus》这本书作了一些简要的介绍，主要是这些工具的用途、使用方
式，及这些工具与XP方法论之间的关系。虽然XP或Agile方法论都不强
调工具，这些方法论都是以人为主。但是如果工具对于人们的工作有所
助益，可以简化工作，提升工作效率与品质，这些工具仍然是值得采用
的。更何况这些工具都是免费或者以很低的价格便可以取得。在本书采
用了大量的范例来说明，除了说明部分细节使用简单的范例外，还设计
了一个完整的项目贯穿所有的工具。本书所附的光盘中包括所有的工具
及范例，你也可以从网站上下载
（http://www.wiley.com/legacy/compbooks/hightower/或
http://www.rickhightower.com/JavaXPToolkit/）。最后本书也将这些工具的
API列出，方便读者参照。同时在笔者的网站『点空间』中也有一些样
章，欢迎前往指教。
*********************************************************************
**
注释：

1.有关『灵活方法论』、XP及重整的详细介绍请参阅笔者的『点空间』
网站（http://www.dotspace.idv.tw）

2.shell是一种「命令解释器」，它等待使用者输入指令，解释指令的内
容，并呼叫指令所指定的应用程序来完成工作，其地位就好象 Microsoft
MS-DOS 系统中的 COMMAND.COM 一样。

3.JUnit是专为Java使用的单元测试工具，其它的语言也有类似的工具，
请参阅http://www.xprogramming.com/software.htm

4.Cactus原来的名称是J2EEUnit，这个名称是比较能够表达这个框架的目
的。但是因为已经Sun拥有J2EE的商标，所以Apache Software Foundation只
好将这个框架的名称改为Cactus。Cactus目前公认为是Jakarta的最高阶专
案，可以与Ant、Tomcat及Struts相提并论。同时Cactus包裹的名称也从
org.apache.commons.cactus改成org.apache.catcus。所以你最好随时注意其
网
页以了解Cactus未来的发展。

5.Cactus及HttpUnit两者都是测试Web应用程序组件。因此主要的问题便是
他们的关系，及应用的领域。虽然两者有些重叠，最基本的差异是Cactus
是比较单元导向（unit-oriented）。Cactus测试主要是检测特定类别的行为
及方法，而HttpUnit则是检测向服务器要求特定的资源。

6.HttpUnit提供检视HTML文件或部分的HTML文件的能力，这个能力就称
为DOM（Document Object Model）。DOM是由World Wild Web Consortium
（http://www.w3.org/DOM/）所发展的一个标准，DOM将文件视为一个可
以操作的对象。DOM允许程序化（programmatic）的存取XML及HTML中
的资料。而JDOM是与XML互动的一种轻量的API，它是Apache的开放程
式码（http://www.jdom.org）。它的API最值得重视的是比DOM更直觉更符
合Java的风格。

7.请参阅GoF所着：《Design Patterns》，修饰者（decorator）样式动态的为
对象附加(attach)责任(responsibilities)。修饰者样式提供一个弹性的继承
替代
方案以扩增功能。

作者	Re:极端软件制程的Java工具 [Re:chaos]
房客版主发贴: 68 积分: 30	于 2003-04-23 23:32 本书台湾译本已经发表本书中国译本将于年中机械出版社出版

作者	Re:极端软件制程的Java工具 [Re:chaos]
floater Java Jedi 总版主发贴: 3233 积分: 421	于 2003-04-24 00:33 This book is one of the pleasant readings. "Any fool can write code that a computer can understand. Good programmers write code that humans can understand." - Martin Fowler, Refactoring - Improving the Design of Existing Code

作者	Re:极端软件制程的Java工具 [Re:chaos]
shajian 发贴: 7 积分: 0	于 2003-05-06 21:56 有指导意义。我看不光可以用于极限编程。

作者	Re:极端软件制程的Java工具 [Re:chaos]
panpa 发贴: 12 积分: 0	于 2003-05-26 15:30 现在国内用这样测试得多吗？

已读帖子

新的帖子

被删除的帖子