Vincent's gossip

圣诞，也来凑个热闹！

SunMicro — Tue, 25 Dec 2007 14:32:20 +0800

作者: SunMicro 链接：http://gossip.javaeye.com/blog/150699 发表时间: 2007年12月25日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

中午休息的时候看了篇文章文章《Ben's Christmas day》，激发了一点Gossip情绪。也说说中美圣诞的差异。
虽不是土鳖节，但也同样搞得有声有色，大有超英赶美的趋势，而且听说去年重庆的热闹程度都超过人家洛杉矶了（根据我的现场观察，很有可能）。都是图热闹，但中美圣诞的差距是相当之大，首先是目标人群的差异，在美国，凑一起的是家人，中国则多是一些死党。准确来讲，美国的圣诞更像是中国的春节（lunar new year）。
中国过圣诞相对来说是比较仓促的，计划时间大概在两三周左右，而美国一般的家庭都是用半年时间来准备，而且相对于中国，美国有一套很完善的圣诞节加热系统（Completed Promotion System),这套系统将在大家吃完Thanksgiving的火鸡后全面启动。由于在Thanksgiving后，美国人民会有他们的新年假期，所以他们将有充足的时间来执行计划了大半年的Christmas Happy方案。另一方面，由于历史传统以及经济发达程度的不同，美国的圣诞节期间要卖到价廉物美的东西还是很容易的，尽管平均商品价格在节日计划执行期会有一定的上调，但商品自身的价值也在提高，而且只要圣诞节一过，商品价格立马回调到普通水平。整个Christmas Commercial System实际上更多的是在回馈社会，皆大欢喜！而中国则混杂了大量的商业臭味在里面，商品价格同期会整体上涨，但价位将从圣诞前期一直持续到春节后期，喜气洋洋的看着爽，聞起来才知道夹了点一氧化碳。
不知道什么时候开始凑圣诞节热闹的，可能是是耶稣势力扩张时期，也可能是网络腾飞年代？至于原因，可能是和谐社会经济的迅猛发展，也可能是扩散在网络上的病毒导致了孤独的极速蔓延。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

lambda算子中的数

SunMicro — Wed, 19 Dec 2007 19:12:32 +0800

作者: SunMicro 链接：http://gossip.javaeye.com/blog/149512 发表时间: 2007年12月19日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

数学基础差加之受严重的功利主义思想的影响，我对数学一直是没有太大兴趣。不过最近一段时间在看《算法导论》和《SICP》，几周下来发现进度之慢，归结原因是大部分数学知识都被我遗弃了，然后看的时候不得不在案头放上离散数学、微积分、线性代数、统计学、运筹学等大学未弃之书作为速查手册，说能快起来那是在自我忽悠。
做程序不能不懂数学犹如绘画不能不懂素描，基本功扎实了才好发挥。但鉴于程序员与数学家还是有本质的不同，不但要保持思维跨度在1到pow(10,15)也就是15个数量级之间还要学习相应业务知识以及应对客户，有点爱好的还要研究下声乐，绘画。这种情况下大可不必去与数学较劲。所以开发人员在数学的学习上最好是贯彻‘广度优先’这一方针，将要应对的问题和与之对应的数学知识在头脑中建立一张dynamic lookup table即可，待到用的时候在去查阅相关资料。即便不知道具体公式，但若能在求最大公约数的时候立马想到欧老前辈，也就算基本合格了。但话说回来，像这种基础的还是记住的好，不然不好意思跟人家说I'm very professional！
废话一大堆，最近才看到SICP的第三章，前面有一些习题也没有来得及做，昨夜在回顾习题的时候碰上了exercise2.6，关于lambda算子中数的表示，这套形式系统中，酷就酷在可以全由lambda演算系统中的合法符号来表示数，通俗的说就是用没有一个数字的表达式来表达数字
SICP中的一个例子
看看数学中0（zero ）是如何用lambda表达式来定义的：

(define zero (lambda(f)(lambda(z) z)))

对于Alonzo Church来说，看上面的代码好比看英语，但对于在数学之海的岸口张望的人来说，不太直观
那再看看one two three

(define one  (lambda(f)(lambda(z)(f z))))
(define two  (lambda(f)(lambda(z)(f (f z)))))
(define three  (lambda(f)(lambda(z)(f (f (f z))))))

似曾相识？那看下面

int zero=0;
int one=zero+1;
int two=one+1;
int three=two+1;

通过这样一对比，很容易就可以得出一个Chruch数与自然数的转化式

;做个过度
(define f (lambda(x)(+ x 1)))
(display (f (f 0)));output 2
;转换式
(define (cn-to-n cn)
	((cn (lambda(x)(+ x 1)))0))

数的表达有了，接下来就是运算了，习题的要求是做了加法运算

(define (add x y)(+ x y))

一个很典型的加法，但不适用于Chruch数
要支持Chruch数的运算，那至少要在运算式中将其表达出来吧。
从前面的定义来看，lambda(f)(lambda(z)..)是跑不了的，由于Chruch数本身即是嵌套的函数表达式,那只要我能将最后的结果组合成(f (f (f ..(f z)..)))这番模样就算大功告成了
这个时候再琢磨一下前面的Chruch数，然后换个写法

(define one   (lambda(f)(lambda(z)(f ((zero f)z)))))
(define two   (lambda(f)(lambda(z)(f ((one  f)z)))))
(define three (lambda(f)(lambda(z)(f ((two  f)z)))))

在Chruch表达式里面(one f)就是one,(two f)就是two,从而推出(x f)=x，再考虑到函数的叠加,试着定义'5',

(define five (lambda(f)(lambda(z)((three f)((two f)z)))))

然后从特殊到一般，得出加法运算式

(define (add x y) 
	(lambda(f)(lambda(z)((x f)((y f) z)))))

习题是完成了，但凡是涉及到数学的问题都有让人去发散思维的魔力，加法都出来了，何不看看乘法，前面定义了五，现在试着定义下六

(define six  (lambda(f)(lambda(z)((three (two f))z))))
;依葫芦画瓢得出乘法定义
(define (mul x y) 
	 (lambda(f)(lambda(z)((x (y f))z))))

解题过程中为求天时地利，坚持坐北朝南，并发扬一贯的连蒙带猜，猜中带推的作风，虽终得正解，但仍不能掩饰数学知识之贫乏，恶补在所难免。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

JVM and Security primary summary

SunMicro — Tue, 12 Jun 2007 14:35:13 +0800

作者: SunMicro 链接：http://gossip.javaeye.com/blog/89457 发表时间: 2007年06月12日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

早期JAVA的安全模型被称作”沙箱（sandbox）“，通过定义这样一个用户可配置的保护域来实现代码的安全性管理，紧接着在JDK1.4中引入了健壮的全功能安全体系，该体系仍然基于沙箱这一概念的，不过新体系的安全策略是向ProtectionDomain授权权限而不是针对单一代码段授权权限

在最初的沙箱定义中，条件过于严格，导致善意的程序运行受限，新的安全平台体系中引入了代码签名和认证的信任模式，在这种模式下，可以根据代码数字签名的可信度给与适当的执行权限，使足够可信度的代码将充分发挥其作用。

沙箱由四个基本部分组成:

类装载器结构
class文件验证
内置与jvm的和语言本身的安全特性
安全管理器和java api

1.类装载器结构

jvm通过类装载器实现类的加载并同时建立不同可信度的命名空间，也叫运行时包，只有被同一类加载器所加载的类相互之间才可见，因为他们在同一命名空间，不同的类加载器会创建不同的命名空间，不同命名空间之间是不允许访问（不可见的。jvm在加载类的过程了使用双亲委托模式，既是发现需要装载某一类的时候，首先将这个任务委托给自己的上级类装载器，依次规律，一般情况下类装载任务最后将委托给启动类装载器，只有在双亲无法完成装载的情况下，才由自己完成装载。双亲委托模式首先降低了恶意代码试图利用系统对java api的信任来达到目的的可能性。设想，一个恶意类被命名为java.lang.String,试图使类加载器误以为该恶意类是java api的一部分，但双亲委托将使用启动类加载器首先寻找java.lang.String，启动类加载器的搜索范围在java api中，当在api中找到这个String类后便会进行加载，而恶意的java.lang.String将不会被加载，也就是说恶意代码无法伪造身份。若恶意代码试图将自己“混"入java API，比如，一个声明为java.lang.IamHack的类，但由于启动类装载器在api中无法找到该类，它只可能被类路径装载器或用户自定义的类装载器装载，所以与api处在不同的命名空间中，仍然无法获得足够的信任

2.class文件验证

这一过程分为四个阶段

⑴文件结构验证

sun定义的class文件具有特定的结构，以0xCAFEBABE开头标识这是一份java特定的class文件（cafe babe,听说是对barista所作贡献的感谢）。class文件的每一个组成部分都声明了其类型和长度，检验器可以以此计算出正确的class文件总长度，从而判断是否有删减或附加额外的代码

下面是一个接口的16进制标识：

0000000: cafe babe 0000 0032 0009 0700 0707 0008 .......2........
0000010: 0100 0564 6f53 7468 0100 0328 2956 0100 ...doSth...()V..
0000020: 0a53 6f75 7263 6546 696c 6501 0009 446f .SourceFile...Do
0000030: 6572 2e6a 6176 6101 0015 6575 746f 7069 er.java...eutopi
0000040: 612f 7365 6375 7269 7479 2f44 6f65 7201 a/security/Doer.
0000050: 0010 6a61 7661 2f6c 616e 672f 4f62 6a65 ..java/lang/Obje
0000060: 6374 0601 0001 0002 0000 0000 0001 0401 ct..............
0000070: 0003 0004 0000 0001 0005 0000 0002 0006 ................
0000080: 0a .

紧接cafe babe的是虚拟机的主次版本号的16进制标识，然后是常量池中的数据个数，常量次的数据在后侧可以看到，这里包括了类名，方法名等，另外还有字符串和特征符。接下来的对类文件中字段和方法的复杂结构表示。

⑵类型数据语义检查

这一过程需要验证class文件中个组成部分的所属实例是否与声明类型相符合，以及该类型是否符合java语言规定的特定条件，比如final类是否被子类化或是final方法是否被覆写等。另外还有java所有类继承自java.lang.Object，常量池中条目是否合法等。

⑶字节码验证

型数据语义检查并不检验class字节码，字节码的检验将在这个阶段完成。JVM使用的是堆栈体系结构，在使用指令操作数（Java为单字节指令序列）必须将其装入堆栈，JVM规范中又将其称作操作码，每一个操作码后面都跟着一个或多个操作数，为JVM执行操作码时提供额外的数据。JVM依次执行每个操作码，这在JVM内部构成执行线程，每个线程被授予一个由不同栈帧构成的JAVA栈，每一个方法调用都对应内存中的一个栈帧，其中保存了方法中的局部变量和中间结果（保存中间结果的为操作数栈）。

这期间要验证操作数栈中的数据是否合法，方法的调用过程是否使用了合法的参数，局部变量的访问是否被允许（访问必须在初始化之后），字节码验证的验证工作量是比较大的，其中还包括了跳转命令的检查等。经过字节码验证后。可以确保class文件的完整性。

⑷符号引用验证

class文件中对其引用的类，方法，变量等是以文字符号描述的，该描述保证准确定位至唯一的目标。类装载器装载一个类的时候会对其中包含的字符引用作出解析，首先是查找被引用的类，但不一定会加载，因为JVM的延迟加载会确保被引用的类在第一次使用前被加载。若找到了对应的类，则将文字描述替换为直接引用，如指针。JVM会记住这些直接引用，所遇到同样的描述，则直接替换为直接引用，从而避免重复查找。

由于JAVA动态链接的特性，可能会导致二进制不兼容，尽管在改动java文件后的重新编译过程中会检查兼容性，但考虑到在运行时加载的类文件在编译时期并不会被检查，所以需要在运行时执行二进制兼容检查。

3.JVM内置安全特性

在执行期，除了符号引用验证，JVM还会对一些内建的安全特性进行检查，大致如下：

类型安全的引用转化
结构化的内存访问(非指针算法)
GC
数组边界检查
空引用检查（NullPoint)

强制内存的结构话访问，避免了恶意用户在了解内存分布的情况下通过指针对JVM的内部结构进行破外。当然要了解JVM的内存分布也不是易事。JVM对运行时数据空间的分配是一个黑盒过程，完全由JVM自己决定如何分配，在class中没有任何相关的信息。

字节码检查的局限就是对于那些不经过字节码检查的方法（如本地方法：native method）无法验证其安全性，所以这里采用的是对动态链接库的访问控制，对于那些足有足够可信度的代码才被允许访问本地方法。具体的实现是，由安全管理器来决定代码是否有调用动态链接库的权限，因为调用本地方法必须调用动态链接库。这样一来，不可信的代码将无法通过调用本地方法来绕过字节码检查。

4.安全管理器和java api

我们建立的java application基本上可以说是畅通无阻的，其原因是默认情况下所有JAVA API的操作都是被允许的。但

如果稍加限制一下

新建一个policy(实际上默认既是为read，这点从java.lang.Class中定义getProtectionDomain()方法中可以看出的)

java 代码

grant codeBase "file:///D:/JavaTestCode/security/securitymanager/" {
permission java.io.FilePermission "D:/JavaTestCode/security/securitymanager/*", "read";
};

codeBase指定要限制的类所在目录：URL
FilePermission 中指定了要保护的文件：资源名称

然后在运行时以

java -Djava.security.manager -Djava.security.policy=policyURL appName

的形式指定

（也可以通过在java.security中以policy.url.n=policyURL的形式指定）。

java 代码

class TrustlessWriter
{
public static void main(String[] args)throws Exception
{
File data=new File("data.txt");
FileWriter writer=new FileWriter(data);
writer.write("this is a test");
writer.close();
}
}

在控制台输入：

java -Djava.security.manager -Djava.security.policy=myaccess.policy TrustlessWriter

结果将是抛出类似java.security.AccessControlException: access denied (java.io.FilePermission data.txt write)的错误信息

这里需要注意policy的格式

policy file syntax

grant signedBy "signer_names", codeBase "URL",
principal principal_class_name "principal_name",
principal principal_class_name "principal_name",
... {
permission permission_class_name "target_name", "action",
signedBy "signer_names";
permission permission_class_name "target_name", "action",
signedBy "signer_names";
...
};

codeBase 需用声明协议类型，若为本地文件话，需以file:声明，FilePermission里面则直接使用目标文件名或通配符

在JAVA2平台安全体系中，访问权限被类型化为对象，也既是说访问权限在Java api中被定义，所有访问权限对象继

承自抽象类java.security.Permission；

所以也可以在代码中启动SecurityManager，并执行检查

java 代码

class TrustlessWriter
{
public static void main(String[] args)throws Exception
{
//SecurityManager sm=new SecurityManager();
FilePermission filePermission=new FilePermission("D:/JavaTestCode/security/securitymanager/data.txt","write");
System.out.println(TrustlessWriter.class.getProtectionDomain());
AccessController.checkPermission(filePermission);//sm.checkPermission(filePermission)
File data=new File("data.txt");
Writer writer=new FileWriter(data,true);
writer.write("hello!");
writer.close();
}
}

此时可省略-Djava.security.manage，执行命令变为：

java -Djava.security.policy=myaccess.policy TrustlessWriter

（AccessController是在JAVA2中引入的，不过考虑到前向兼容，新的平台安全体系中仍然可以使用SecurityManager

来做检查，但SecurityManager的所有check方法均调用AccessController的checkPermission）

关于代码签名和认证

新安全平台中对足够信任度的代码放宽了限制，要获得充分信任须通过代码签名来实现，若我们对某一签名团体足够信任，比如SUN，那么具有该团体签名的代码将被给予充分信任。一个基本的思路大致为，代码发布者创建私钥/公钥对，然后利用私钥对发布代码进行签名，代码使用方在获得代码发布者提供的公钥后对代码进行验证，确认代码确为该提供者提供以及在发布后未经非法修改。这其中存在一些潜在的危险，既是公钥是否是该代码发布者提供的，恶意用户可能替换掉合法的公钥，这会导致用户将给与恶意用户发布的代码以充分信任，目前的常见做法是通过一些权威的证书机构来发布证书而不是公钥，代码发布者被证书发布机构认证合格后，可以将自己的公钥交付证书发布机构，证书发布机构再通过私钥加密该公钥，从而生成证书序列。这样替换公钥的可能性就变得微乎其微。不过世上无绝对安全之事，通过证书机构发布的证书也不是绝对安全的途径。

对代码进行签名需要将所有class文件打包入jar，然后通过jarsigner对其进行散列计算。

一个简单的示例：

1.首先将CredibleDoer.class打包至 credible.jar:

jar cvf credible.jar eutopia/security/CredibleDoer.class

2.创建别名为credible的密钥对，将其保存在至doerkeys：

keytool -genkeypair -alias credible -keypass douyourwant -keystore doerkeys

3.为credible.jar进行签名：

jarsigner -keystore doerkeys -storepass 111111 -keypass douyourwant credible.jar credible

完成对一个jar文件的签名后，会在jar产生两个文件，此处为credible.SF和credible.DSA

.SF文件保存了一个所有类的列表以及了签名过程中使用的摘要算法，大致如下：

credible.sf

Signature-Version: 1.0
SHA1-Digest-Manifest-Main-Attributes: 9QUCJMHnILftziSD8agLig+iUN8=
Created-By: 1.6.0 (Sun Microsystems Inc.)
SHA1-Digest-Manifest: Z1288OdOqrP+Kstqxv0pS10Je7o=
Name: eutopia/security/CredibleDoer.class
SHA1-Digest: ODGgb1aB9Ht0iVwmfhGSU6pRneo=

DSA文件是一个二进制密匙文件。

验证完整性实验：

现在通过jarsigner -verify credible.jar对该文件进行验证。若文件未经改动，一切正常

若签名后再将TrustlessDoer.class加入credible.jar且不更新签名，那么验证结果将会给出警告：

警告：
此 jar 包含尚未进行完整性检查的未签名条目。

若是替换原有class文件，比如这里替换CredibleDoer.class，将会有类似下面的错误提示：

jarsigner： java.lang.SecurityException: SHA1 digest error for eutopia/security/CredibleDoer.class

通过 keytool -exportcert -file credible.cer -alias credible -keystore doerkeys 可以导出cer正式文件，其中保存了签名的一些基本信息以及公钥

创建密钥对的算法有DiffieHellman，DSA ，RSA， EC可以通过-sigalg <算法名>指定算法，比如：

keytool -sigalg DSA -genkeypair -alias credible -keypass douyourwant -keystore doerkeys

参考：JavaTM Cryptography Architecture API Specification & Reference的Appendix A: Standard Names以及Appendix B: Algorithms

Related Data

深入java虚拟机第二版

Permissions in the JavaTM 2 Standard Edition Development Kit (JDK)

JavaTM Cryptography Architecture API Specification & Reference

Java 安全性架构文档

JavaTM 2 Platform Security Architecture

Default Policy Implementation and Policy File Syntax

Java 授权内幕

J2EE 探索者: 用 JAAS 和 JSSE 实现 Java 安全性
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

Lambda Calculus

SunMicro — Thu, 19 Apr 2007 10:34:29 +0800

作者: SunMicro 链接：http://gossip.javaeye.com/blog/72394 发表时间: 2007年04月19日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

λ演算是一套用于研究函数定义、函数应用和递归的形式系统。它由 Alonzo Church 和 Stephen Cole Kleene 在 20 世纪三十

年代引入，Church 运用 lambda 演算在 1936 年给出判定性问题 (Entscheidungsproblem) 的一个否定的答案。这种演算可以

用来清晰地定义什么是一个可计算函数。关于两个 lambda 演算表达式是否等价的命题无法通过一个通用的算法来解决，这是

不可判定性能够证明的头一个问题，甚至还在停机问题之先。Lambda 演算对函数式编程有巨大的影响，特别是Lisp 语言。

Lambda 演算可以被称为最小的通用程序设计语言。它包括一条变换规则 (变量替换) 和一条函数定义方式，Lambda 演算之通

用在于，任何一个可计算函数都能用这种形式来表达和求值。因而，它是等价于图灵机的。

尽管如此，Lambda 演算强调的是变换规则的运用，而非实现它们的具体机器。可以认为这是一种更接近软件而非硬件的方

式。

有界vs自由

python 代码

(lambda x,y:x+y)+x+y+z

lambda表达式中的x，y与外部x，y显然是不同的，为了区别两者，引入了有界和自由的概念。lambda只能处理有界的标识

符。

当一个标识符出现在了lambda的参数里面，并包含在了这个lambda表达式中，那么就称其有界限，反之无界。

python 代码

(lambda x,y:x+y)+x+y+z

x,y被包含在了lambda表达式中，所以其有界，而z没有那么他就是自由标识符,虽然y在lambda的参数中，但并没有在表达式中

出现。那么他就是自由的

有界和自由是一个相对的概念

python 代码

(lambda x:(lambda y,z:y+2))

相对于内嵌的lambda，z是自由的，因为在内嵌的表达式中并没有z出现，然后相对于整个lambda表达式，它又是有界的。

“free（x）”代表表达式x所有的自由变量集合

判定lambda表达式完全合法的标准是它的所有变量都是有界的。

上例中(lambda x,y:x+2)虽然可以在程序中正常执行，但其实是一个不完全合法的lambda表达式

lambda算子计算规则

alpha，beta，eta

alpha(conversion)(转换规则):

简单来说就是重命名规则(但被绑定的变量能否由另一个变量替换有一系列的限制）：

lambda x,y:x+y与lambda m,n:m+n是等价的

beta(reduction)(归约)

将lambda表达式中的有界变量替换为应用中对应得实际值

(lambda x,y:x+y)(2,3)等价于2+3

Beta的严格定义：

lambda x . B e = B[x := e] if free(e) \subset free(B[x := e]

考虑这样一种情况

python 代码

(lambda x:(lambda y:x+y)(x+3)

其等价的表达式现在是

x+x+3

这里的问题是lambda中得有界变量与（x+3)中得自由变量有冲突，两则是不同的，需要区别

alpha[x/z]：(lambda x:(lambda y:x+y)(x+3)=(lambda z:(lambda y:z+y)(x+3)

现在展开后就是z+x+3，正确结果

eta(变换)
Eta表达的是外延性的概念，在这里外延性指的是，两个函数对于所有的参数得到的结果都一致，当且仅当它们是同一个函数。

(python中的lambda不等价与该处所指的lambda）
www.wikilib.com/wiki
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

XP basis

SunMicro — Wed, 18 Apr 2007 11:51:46 +0800

作者: SunMicro 链接：http://gossip.javaeye.com/blog/72164 发表时间: 2007年04月18日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

what is Extreme Programming

simple design:什么是简单的设计，简单的说就是可以很容易使你团队成员理解并认同的设计，过犹不及

不少人总是喜欢炫耀自己所掌握的设计模式和最新的设计技巧，而全然不考虑是否

合适。简单的设计包含两个部分，其核心就我所理解既是把握现在而非充满变数的未来，第一部分：为已经

定义的功能进行设计，或说是和客户协商好了的需要实现得功能，不要将自己一些自以为是的GOOD IDEA强加

于设计。第二部分：创建最佳的可实现功能得设计，不管未来怎样，我们只将眼前的工作做到最好。似乎敏

捷是有意在回避预测，而实际上的原因是敏捷不惧怕改变，。Kent Beck就这个问题专门有写到：“只有在你

正真需要的时候才去做”，敏捷提倡的“适应”,迭代开发可以很方便的改变原来的主意，在这个前提下预测

是多余和危险的，由预测所产生的内容在面对改变的时候，代价是昂贵的！

refactor：目的是提高代码的质量，使项目在细节上面得到优化，其实这里的概念还比较模糊，什么是高质

量的代码呢，如CodeComplete所述，不同性质的项目有不同的判定标准，是小型的桌面应用，一般的商用软

件还是性命攸关的核心控制程序。这需要在稳定，可扩展，易修改等特性中寻求最佳。当然前提是代码简

单易懂。

test:代码要易于测试，什么样的代码才容易测试呢，当然是以测试为前提写出来的代码。Test-Driven Development说得就是

“测试先行”，简单说来就是，先写一个测试程序，定义通过和失败的判断标准，然后以定义的通过标准为目标，实现product

code.除了是porduct代码容易测试外，TDD还有助于你充分理解你的设计，试想若你对要实现的功能不明确，又如何能写出测

试程序呢？

pair-programming:存在有不少的争议，多数的反对意见是效率不高。XP关于Pair-Programming的描述：

All code to be included in a production release is created by two people working together at a single computer. Pair programming increases software quality without impacting time to deliver. It is counter intuitive, but 2 people working at a single computer will add as much functionality as two working separately except that it will be much higher in quality. With increased quality comes big savings later in the project.

很明显，是为了提高代码质量，避免潜在的错误和不当设计，因为在这个过程中其同时发生的还有Walkthrough和Inspection等

活动。另外两个人一起工作，偷懒的可能性大幅减少而且解决问题的能力会加强，而且大量实践证明，pair-programming是提

高软件质量和减少开发时间的有效方法，当然，前提是合理的利用。

www.xprogramming.com/index.htm

www.extremeprogramming.org/index.html
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

engineering methodologies VS agile methodologies

SunMicro — Tue, 17 Apr 2007 13:52:29 +0800

作者: SunMicro 链接：http://gossip.javaeye.com/blog/71857 发表时间: 2007年04月17日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

www.martinfowler.com/articles/newMethodology.html#FromNothingToMonumentalToAgile

engineering methodologies（工程方法，又或则plan-drive methodologies,计划驱动方法），这些方法通

过对开发过程进行严格而详细的规定，以期使软件开发更可预知以及获得更高的开发效率，这种强调前期计

划灵感来源与其他工程领域的实践，从而得名工程方法。不过工程方法虽然存在了很长时间，但并没有引起

人们太多的注意，对其主要的评批是太过于个官僚化，太多德事情需要做，会延缓整个开发进程。

agile methodologies(敏捷方法）以对工程方法的反其道而行得以发展，主要是在无过程和过度过程中寻找

一种平衡，即从合理的过程中获得满意的回报。

敏捷方法与工程方法有一些明显的区别，其中之一反映在文档上，敏捷方法不是面向文档（document-

oriented）的，其倡导的是在给定的任务中使用更少的文档，敏捷方法更象是面向代码（code-oriented）：

文档的核心应该是源代码

文档方面的特点并不是敏捷方法的关键所在，文档减少只是表象，其更深层次的特典是：

1.敏捷方法是强调“适应”而不是“预见”，工程方法试图在代码构建之前定制一个详细的计划，若项目庞

大，那么就需要在一个很长的时间跨度内作出详细计划。然后依照计划进行开发。这种方法的本质是拒绝变

化的。而敏捷方法强调的是“welcome change”，其目的就是设计出适应变化的过程，甚至通过改变自身来

适应变化。

2.敏捷方法是面向人（people-oriented）而非面向过程（process-oriented）的，工程方法的目标是定义一

个适合所有人使用的过程。而敏捷方法则认为没有任何过程可以替代开发组的技能，所以过程的作用应该是

为开发组提供支持

将设计与建造分离开来？

    《代码大全》的部分比喻在Martin Fowler的文章中显得有些不合适了，软件工程不同于传统的工程项目，比如土木工程。工

程方法的思路类似与传统的工程项目，将设计与建造完全分开，因为在传统的工程项目了，设计与建造是两个截然不同的活

动，设计是难以预计的，需要昂贵的有创造性的人员，建造过程则比较机械，只需要按部就班的工作，这样在建造过

程中就能使用技能相对较低的人员。然后土木工程与软件工程存在许多不同，首先，土木工程中，设计相对与建造无论是在时

间上还是经费上都要少得多。但软件工程中编码所占的时间一般要少的多，McConnell 指出在大型项目中，编码和单元测试只

占15％，这几乎和桥梁工程中的比例倒过来了。即使把所有测试工作都算作是建造的一部分，设计仍要占到50％。

对比软件工程和传统工程，可以得出一些结论:

    1.在软件开发中，具体建造费用低得可以认为是没有。

    2.软件开发中所有工作都是设计，因此需要富有创造性的才智之士。

    3.创造性的过程是不太容易计划的，因此，可预见性或许是个不可能达到的目标。

    4.我们应该对用传统工程来隐喻软件构造保持足够的警觉，因为它们是不同类型的活动，需要不同的过程。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

Pluggable Adapters

SunMicro — Mon, 09 Apr 2007 21:34:00 +0800

作者: SunMicro 链接：http://gossip.javaeye.com/blog/69351 发表时间: 2007年04月09日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

A pluggable adapter is an adapter that adapts dynamically to one of several classes. Of course, the adapter can adapt only to classes that it can recognize, and usually the adapter decides which class it is adapting to based on differing constructors or setParameter methods.

Java has yet another way for adapters to recognize which of several classes it must adapt to: reflection. You can use reflection to discover the names of public methods and their parameters for any class. For example, for any arbitrary object you can use the getClass method to obtain its class and the getMethods method to obtain an array of the method names.

java 代码

/*
*Adaptee
*/
class Pathfinder
{
public void explore()
{
System.out.println("explore");
}
}
/*
*Target
*/
class Digger
{
public void dig()
{
System.out.println("Dig");
}
}
/*
*Target
*/
class Collector
{
public void collect()
{
System.out.println("collect");
}
}
/*
*Adapter
*/
class PluggablePathfinderAdapter
{
private Pathfinder pathfinder;
private HashMap map=new HashMap();
PluggablePathfinderAdapter(Pathfinder pathfinder)
{
this.pathfinder=pathfinder;
}
public void adapt(String classname,String methodname)
{
try
{
Class _class=Class.forName(classname);
Method method=_class.getMethod(methodname,null);
map.put(classname,method);
}catch(ClassNotFoundException cnfe)
{
cnfe.printStackTrace();
}catch(NoSuchMethodException nsme)
{
nsme.printStackTrace();
}
}
public void explore(String classname)
{
try
{
pathfinder.explore();
map.get(classname).invoke(Class.forName(classname).newInstance(),null);
}catch(Exception e)
{
e.printStackTrace();
}
}
}

java 代码

public class PluggableAdapterDemo
{
public PluggableAdapterDemo()
{
}
public static void main(String[] args)
{
Pathfinder pathfinder=new Pathfinder();
PluggablePathfinderAdapter adapter=new PluggablePathfinderAdapter(pathfinder);
adapter.adapt("Digger","dig");
adapter.adapt("Collector","collect");
adapter.explore("Digger");
}
}

本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

Lazy Loading Singletons

SunMicro — Fri, 23 Mar 2007 10:08:18 +0800

作者: SunMicro 链接：http://gossip.javaeye.com/blog/64855 发表时间: 2007年03月23日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

今天在论坛看见一小段代码，不得不佩服作者（blog）的创新精神。以前在使用Singleton的时候大多采用这样的方式：

java 代码

public class Singleton {
static Singleton instance;
public static synchronized Singleton getInstance() {
if (instance == null)
instance = new Singleton();
return instance;
}
}

但这里的问题是synchronization实际上只在getInstance()第一次调用的时候需要，这个方法在多线程频繁调用的应用中必然会成为效率的瓶颈。

到了java1.5，Bob Lee提到了 Double-Checked Locking (DCL) ，并强调了是infamous DCL；这种做法强调了效率（但Bob Lee认为volatile 不比synchronized快，另外这种做法会产生更多的代码，所以仍然坚持使用plain old synchronization），并不将整个方法synchronized，而是只对创建Singleton进行同步，这样，线程进入getInstance()，发现instance 已经创建，就会直接返回instance，而不用在方法外等待。

在这种情况下，Singleton的实现代码一般是这样：

java 代码

static volatile Singleton instance;
public static Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class) {
if (instance == null)
instance == new Singleton();
}
}
return instance;
}

接下来是 Bob Lee的创新做法：

java 代码

static class SingletonHolder {
static Singleton instance = new Singleton();
}
public static Singleton getInstance() {
return SingletonHolder.instance;
}

JLS将保证Singleton instance只在第一次调用getInstance()的时候创建。优雅且快速！
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐