Selenium分为两种运行模式，Driven Mode(现在叫Selenium Remote Control)和FIT Mode(现在叫Selenium Core)。

FIT Mode顾名思义，就是类似FIT Testing Framework那种使用方式，主要用于QA等非技术人员编写Web应用的功能测试。FIT Mode的Selenium测试使用HTML来组织测试用例。例如我要测试一个web应用的登陆功能。我可能写出这样的HTML 表格。

 1 < table >
 2 < tr >
 3   < td > open </ td >
 4          < td > http://localhost:8080/login </ td >
 5          < td ></ td >
 6 </ tr >
 7 < tr >
 8   < td > type </ td >
 9          < td > id=username </ td >
10          < td > someuser </ td >
11 </ tr >
12 < tr >
13   < td > type </ td >
14          < td > id=password </ td >
15          < td > password </ td >
16 </ tr >
17 < tr >
18   < td > click </ td >
19          < td > id=login_button </ td >
20          < td ></ td >
21 </ tr >
22 < tr >
23   < td > assertTextPresent </ td >
24          < td > Welcome to xxxx </ td >
25          < td ></ td >
26 </ tr >
27 </ table >

不同于FIT，Selenium内置了一系列的命令，如上例中的open, type, click以及assertTextPresent，因此QA可以完全抛开DEV独立地编写测试(FIT需要DEV提供Behavior Fixture)。因此FIT Mode是相当容易使用的，哪怕不会使用HTML的QA，也可以使用FrontPage画出三列表格，依次填入数据。

然而对于大多数team而言——尤其是敏捷team，FIT Mode平易的外表下是令人恐惧的泥沼。大多数团队往往选择使用Selenium作为功能测试和集成测试工具而不仅仅是QA测试工具，在不同的迭代间遇到功能流程或UI变化时，必须要重构Selenium测试，或者说，Functional Test Migration。令人遗憾的是，HTML based的Selenium FIT Testing的重构竟然令人难以置信的困难。我们可以使用include等Selenium FIT扩展，使得它可以重用详细的功能（Log in， Log out诸如此类）。即便如此，在一个真实的项目中，Selenium Test的数量往往在200-500之间(我目前所处的项目在改用Driven Mode前已达350+)，对于这么大基数的Selenium测试，手工重构几乎是不可想象的，而目前尚没有HTML代码重构工具。即便存在泛泛意义上的HTML重构工具，对于Selenium测试重构的有效性尚待商榷。而使用Driven Mode上述代码可以写为:

1 public   void  testShouldShowAWeclomeMessageAfterUserLoggedIn()  {
2     selenium.open( " http://localhost:8080/login " );
3     selenium.type( " id=username " , " someuser " );
4     selenium.type( " id=password " ,  " password " );
5     selenium.click( " id=login_button " );
6     assertTrue(selenium.isTextPresent( " Welcome to xxxx " ));
7 }

很自然，一个训练有素的程序员会重构出如下代码:

 1 public   void  login(String username, String password)  {
 2     selenium.open( " http://localhost:8080/login " );
 3     selenium.type( " id=username " ,username);
 4     selenium.type( " id=password " , password);
 5     selenium.click( " id=login_button " ); 
 6 }
 7
 8 public   void  testShouldShowAWeclomeMessageAfterUserLoggedIn()  {
 9     login( " someuser " ,  " password " );
10     assertTrue(selenium.isTextPresent( " Welcome to xxxx " ));
11 }

之后无论是pull up到公共基类还是extact到Utils class都是很容易的事情。由于Java在代码重构上便利，Java Selenium Remote Control成为使用Selenium的最佳方式。在这一点上，纵使Ruby语法上比Java简单灵活得多，它仍不是编写Selenium测试的最佳载体(当然一个经过精心设计的ruby selenium dsl wrapper还是具有非凡的价值的，这个我们后面会涉及到)。

2. Using the name user, system, page instead of selenium

观察上面提到的代码，其中使用selenium来操纵web应用的行为，这在Remote Control里是常见的做法，但是仍然不够好，我们可以做一些小的变化以得到更好的测试:

 1 protected   void  setup()  {
 2     selenium  =    //  intialize selenium instance
 3     user  =  selenium;
 4     currentPage  =  selenium;
 5 }
 6
 7 public   void  login(String username, String password)  {
 8     user.open( " http://localhost:8080/login " );
 9     user.type( " id=username " ,username);
10     user.type( " id=password " , password);
11     user.click( " id=login_button " ); 
12 }
13
14 public   void  testShouldShowAWeclomeMessageAfterUserLoggedIn()  {
15     login( " some guy " ,  " password " );
16     assertTrue(currentPage.isTextPresent( " Welcome to xxxx " ));
17 }

基本上这只不过是"另一种写法"而已，但是它更好的表达了"用户的行为"，如login代码所示。以及"系统的正确相应"，即currentPage.isTextPresent()。这种是典型的对编译器无意义对人有意义的代码，也就是普遍意义上好的代码。

3. Creating a DSL base on your test codes

懂得HTML的QA可以在没有DEV的帮助下使用Selenium FIT mode，然而却不能在没有DEV的帮助下使用Driven Mode。于是最自然也是最fashion的做法，就是在已有的test codes之上提供Testing DSL或者Scripting Language，让FIT mode变得更加FIT。这方面内容是一个更大的主题，以后再详细展开吧。

4. Hacking Selenium Object to support FIT command

Selenium FIT mode和RC mode下的命令有些许差异，比如FIT中的assertTextPresent，在RC中变成了isTextPresent。同样还有FIT中最实用的命令clickAndWait，在RC中变成了click和waitForPageToLoad。在RC中使用FIT mode中的命令也非难事，找到com.thoughtworks.selenium.Selenium，添加方法:

public   void  doCommand(String commmand, String parameters);

然后在com.thoughtworks.selenium.DefaultSelenium中添加实现:

1 public   void  doCommand(String commmand, String parameters)  {
2    String[] paras  =   new  String[] { "" , "" , "" }
3     for  ( int  i  =   0 ; i  <  parameters.length  &&  i  <   3 ; i ++ )
4       paras[i]  =  parameters[i];
5    commandProcessor.doCommand(command, paras);
6 }

然后试验一下:

selenium.doCommand( " clickAndWait " );

在我们使用纯RC mode之前曾经用过一段中间方案，将rc code转化为fit code来跑(因为rc不支持https)，由于不是真正的rc mode，像isTextPresent之类的方法都没有办法使用，只能使用FIT mode command。因此如果因为一些特殊的原因(https, chrome起不来，hta bug多等等)，你没有办法使用RC mode，但是有希望得到RC可重构的好处，那么这个tricky的技巧倒是不错的选择。

5. Using chrome and IE hta lanucher to support https
6. Run test using different browser lanucher to test browser compatibility

这两个都是和browser lanucher相关的，Selenium和JWebUnit最大的不同在于它使用真实的浏览器来跑测试，从而可以更加真实地考察系统在不同浏览器中的表现。因此使用不同的浏览器lanucher来运行测试，可以更好测试应用的浏览器兼容性，这对于web 2.0应用而言是很有帮助的。此外，使用rc提供的试验性lanucher，chrome和hta可以解决跨domain测试和https的问题。不过目前hta还是有很多bug的，推荐使用chrome。当然，最希望的还是澳洲的同事可以早日在selenium里提供https支持。

老庄是反对一切皆对象的，而TrustNo1在javaeye的一篇帖子上说:

第一，我可以很负责的说,OO的，70年代成型，80年代在理论基础上就给人毙掉。从这种意义上说不是OO死不死的问题，而是OO还活着么？当然理论基础给人毙掉，不是说没有用。

我先说面向对象的理论基础的问题，至于一切皆对象稍后再表。

所谓面向对象的理论基础其实是没有的，原因很简单，面向对象根本就不是一种计算模型。在第一次软件危机的那个时代，对与计算机的非数值计算应用的讨论以及对于可计算性问题的研究和发展，大抵确立了几种主流的计算模型：递归函数类，图灵机，Lambda演算，Horn子句，Post系统等等。

其中递归函数类是可计算性问题的数学解释;图灵机是图灵解决可计算问题的时候所设计的装置，其后成为计算机的装置模型，与图灵机相关的形式语言和自动机成为了命令式语言的理论基础;lambda演算成为了函数式语言的理论基础;Horn子句是prolog这类逻辑语言的理论基础。但是我们惊讶的发现，面向对象没有计算模型的理论基础，换而言之，面向对象根本就不是从可计算性的研究上发展过来的，那么面向对象的理论基础的价值本身就不大。

所以我很奇怪的一个问题就是TrustNo1所谓的面向对象在80年代理论基础上给人毙掉的说法是从何而来的？既然面向对象本质上不是一种计算模型，那么它大抵上只能归结为一种应用技术，应用技术自然可以从各种不同的领域里得到相似的应用，那么毙掉的理论基础所指的又是什么呢？甚怪之。

既然面向对象不是一个计算模型，那么我们可以从不同的角度推断出OO的各种形态，老庄已经出给了从ADT引出OO的问题以及例子，我就不罗嗦了，我给一个从Functional Programming出来的例子，其实就是SICP里的Data as Procedure。

(define (make-user name age sex)
  (define (dispatch message)
     (cond ((eq? message 'getName) name)
           ((eq? message 'getAge) age)
           ((eq? message 'getSex) sex))
           (else (error 'messageNotUnderstand))))
  dispatch)

然后我们就可以

(define vincent (make-user 'Vincent 24 'Male))
(vincent 'getName)

自然的，如果我调用

(vincent 'sayHi)

会得到一个messageNotUnderstand的runtime错误，这就是一个很自然dyanmic type的对象封装，最早的面向对象系统Smalltalk和CLOS基本上都是这个路子，于是有一个问题，为什么最早的面向对象系统都是dyanmic type？这里就跟lambda演算有关了。

lambda演算这个计算模型根本的一个假设就是，对于任何一个定义良好的数学函数，我都可以使用lambda抽象来表述他的求值，因此无论是什么东西你能够构造lambda抽象的话，我就能计算。这个地方东西很多，大家可以找找lambda演算相关的资料，这里我说三件事(由于lambda太难输入，我用scheme程序代替，然后由于alpha变化，beta规约和eta规约我也用scheme伪码来模拟。)

第一个是数值的表述，其实这个很简单，不考虑丘奇代数的系统的话，我们可以把数值表示成单值函数:

(define one (lambda (x) 1))

这个东西无论给什么x都返回1，然后根据lambda演算里的alpha变换，这个lambda抽象等价于数值1。因此，对于所有的数值，我们可以按lambda演算处理。

第二个是bool的表达，也就是如何逻辑进行lambda抽象，下面我直接给出了，缺省认为大家都看了SICP，对Scheme也颇有心得。

(define true-new (lambda (x y) x)) ;;;这个函数也叫select-first
(define false-new (lambda (x y) x));;;这个函数也叫select-second

(define if-new (lambda (conditon if-true if-false) (condition if-true if-false)))

然后我就可以做一个测试

(if-new true-new 3 4)
3

(if-new false-new 3 4)
4

因此，对于所有bool我们可以按lambda演算来处理

第三个是自定义类型，这里我们还是先看一个Lisp里的例子，序对。

(define (cons a b) (lambda (dispath) (dispatch a b)))
(define (car list) (list select-first))
(define (cdr list) (list select-second))

这里依旧是high-order，我们来测试

(define list1 (cons 1 2))
(car list1)
1
(cdr list1)
2

这里大家自己用beta规约算一下，就发现的确是这样的。这里我们又可以看到，在lambda演算里，根本没有数据或者类型。有的永远各种各样的lambda抽象而已(目前已经有了带类型的lambda演算)。这里说一句题外话，SICP里的Data as Procedure其实就是在说这个问题，不过他没明说，而是用了一种特殊的用法而引出了消息传递风格，我觉得这里SICP有些顾此失彼，对于data as procedure我总结的一般形式是

(define (construct-function value1 value2 value3 value4valuen) (lambda (dispatch) (dispatch value1 value2 value3 value4valuen)))
(define (select-function1 data) (data select-first))
(define (select-function2 data) (data select-second))
.
(define (select-functionn data) (data select-last))

综上所述，我们看到在lambda演算里，一切都是lambda抽象，然后对于不同的lambda抽象使用alpha变换，beta规约和eta规约，表述各种不同计算。看，在面向对象之前就已经有了一切皆某某的完美的计算理论存在了。而且回顾一下：

(define (make-user name age sex)
  (define (dispatch message)
     (cond ((eq? message 'getName) name)
           ((eq? message 'getAge) age)
           ((eq? message 'getSex) sex))
           (else (error 'messageNotUnderstand))))
  dispatch)

(define vincent (make-user 'Vincent 24 'Male))
(vincent 'getName)

我们有理由说，对象其实就是一个lambda抽象，所以一切皆对象不过是一切皆lambda抽象的演化，这也是为什么SICP里把面向对象称作一种“方便的界面”而不是一种抽象的方法的原因了。那么对象和lambda抽象又什么区别呢？

嘿嘿，熟悉FP的人都应该知道了，就是Side-Effect，副作用。对象允许对其内部状态进行修改，那么这个东西就破化了eta规约的前提条件，也就是说允许修改内部状态的东西，已经不是一个可以进行lambda计算的lambda抽象了。因此暂且给一个别的名字吧，就叫对象吧.....因此我认为，对象很大程度上是一种带有副作用的lambda抽象。

我在有一篇blog上写了Say sorry to object-oriented，里面给了一只用对象作分支的例子，这里就不重复了，有兴趣大家可以去看一下（刚才好像在JavaEye上看到一个说法，说Everything is Object是Smalltalk的广告语，唉，Smalltalk里的的的确确everything is object啊。）

这里我们来总结一下，面向对象作为一种“方便的界面”主要解决了一个局部化和模块化的问题，这是从lambda演算和函数编程的角度来看面向对象技术。（taowen在他的一篇blog上说，面向对象局部化了Side-Effect，我深以为然），这个东西我个人认为更加接近面向对象本来的意思，而不是由ADT里发展出来的带类型的对象系统的那个意思。因此老庄不以为然的面向对象类型系统，我也不以为然。但是面向对象作为lambda抽象的界面，我觉得还是很不错的。这一点在Smalltalk和Ruby里都有不错的体现。

前面已经说过了，继承至少有2个语义: 实现继承和类型继承，在说明这两个东西之前，我们继续来看上面的例子

Person>>playSoloOnInstrument:instrument
  instrument playNote: Note C;
             playNote: Note D;
             playNote: Note E.

Person>>playBackgroundOnInstrument:instrument
  instrument playChord: Chord C1;
      playChord: Chord C1;
             playChord: Chord C1;

Person>>playBWV996OnInstrument:instrument
   instrument playNote: Note C;
              playChord: Chord C;
              playNote: Note D.

现在我们看playBWV996这个消息，BWV996是Bach所写一个鲁特琴组曲，鲁特琴是弹拨乐器，同时也是和声乐器(所谓和声乐器就是可以演奏和声)。在很多乐器上都有改编的版本，比如鲁特琴的近亲吉他等等，这个时候，我们可以实现这样几个类

Lute>>playNote:note
  
Lute>>playChord:note
  

Guitar>>playNote:note
  
Guitar>>playChord:note
  

Bass>>playNote:note
  

然后我们可以尝试以此调用

vincent.playBWV996OnInstrument: Guitar new.
vincent.playBWV996OnInstrument: Lute new.
vincent.playBWV996OnInstrument: Bass new.

最后一个会得到一个messageNotUnderstand的错误。也就是说，对于Bass而言由于不能演奏和声从而不能演奏BMV996(不过这个世界上能人太多了...哎)，我们换到静态类型面向对象系统来看。
对于第一个方法，playSolo的时候我们要求的类型是能够演奏单音的。我们可以写出来

1interface SoloInstrument {
2  SoloInstrument playNote(Note note);   
3}

对于第二个方法，playChord的时候我们要求的类型是能够演奏和弦的，我们可以写出来

1interface ChordInstrument {
2  ChordInstrument playChord(Chord note);   
3}

而对于第三个方法，playBWV996的时候我们要求既能演奏和弦也能演奏单音，这个时候出现一个问题，我们怎么处理Instrument的继承关系?一个能演奏和弦的乐器是否可以演奏单音(答案是一般而言是的，但是也不排除有一些不是这样的)?还是我们简单的写:

1interface SoloAndChordInstrument extends SoloInstrument, ChordInstrument{
2}

或者

1interface BWV996Playable {
2
3  BWV996Playable playNote(Note note); 
4  BWV996Playable playChord(Chord note);  
5}

对于动态类型简单的隐性类型约定，显示的类型系统带来的一个副作用就是我们必须处理类型之间的关系。注意这里是类型之间的关系，而不是对象之间的关系。老庄同志批了很多篇的面向对象的抽象，面向对象的类型系统以及面向对象的本体论，其实都在是在类型关系上折腾，而不是在对象关系上折腾。而事实上面向对象的类型系统并非必然就是静态类型系统，而我们的类之间的关系不一定就和类型的关系相一致。就像上例所示，在Smalltalk里，Lute，Guitar和Bass之间没有任何的继承关系，但是对于person的3个消息而言，它们却是有类型的。

因此老庄所批的，是对象类型系统的抽象能力，而非面向对象的抽象能力。正如他在类型系统里所给的例子，那张他认为很失败的面向对象的图，其实可以完全不依赖继承来实现，而对这个类型系统的消费者而言，他们能够以一定的类型的观点，来处理这个系统的对象。

而老庄最后一个结论:

我的结论是：“一个类型，是由其本质决定了所能表现出的可操作性，而不是有其所能接受的操作决定了其本质。然而，OO正好把这个问题搞反了！”

我的看法是，这句话根本就是诡辩，前面半句的主语是“一个类型”，后面半句的主语是"OO"...

虽然前半句是对的，但是换一样说法可能更好:"所能接受的操作反映了其本质"，面向对象本身就没有说我要做一个本质抽象，这一点在Smalltalk的类型判断操作上的可能是一个佐证，Smalltalk用isKindOf来判断继承关系，我们来玩一个文字游戏，改成俚语就是kinda，也就是"有一点，有几分"的意思，而不是说，“就是”，或者“从分类学上可证明之类的含义”。我再举一个龌龊的例子。

vincent ballon: AirBallon new.
vincent ballon: Condom new.

气球和保险套，对于ballon这个方法而言是一个类型，都是"有几分"可以吹起来。但是我怎么定义一个精确的本质？Ballonable？还是MakeFromLatexAndVeryThin?或者简单说FlexableAndThin？

在继承这一点上，我想老庄引文中:Elminster的话是从事物的特征与属性归纳出它的“类型”。恰恰对于静态类型面向对象系统是可行的。如我前文所述，我把一个object和所有sender的约定（也就是interface），继承在一起，恰恰就是一个颇为恰当的类型定义。

而对于动态类型系统里的面向对象语言，继承的也有类型继承的含义，但是并不是唯一的途径。用一句我们常说的话，在静态类型系统里，类型和类是紧耦合的，动态类型系统中他们的耦合比较松。

从此而观，所有对于面向对象的哲学考虑以及本体的思考，对于动态面向对象系统已经不是那么迫切了。而把对象类型系统的不足归咎于面向对象的不足，也似乎论据不足。

关于接口的问题老庄说对了，这个东西并不属于面向对象的概念，而且在动态类型面向对象语言(比如Ruby, Smalltalk里)，根本没有这个东西。这是一个纯粹的静态类型面向对象语言的特性，或者直接说，接口就是一个纯类型(Type)。还是上次的例子：

 1interface Instrument {
 2   void playNote(Note note);
 3   void playChord(Chord chord);
 4}
 5
 6in Person Class
 7
 8void playSolo(Instrument instrument) {
 9 
10}

在我接触Smalltalk的最开始的一段时间里，这种地方是让我最难受，我已经习惯了用类型辅助我的思维，但是我发现我在Smalltalk里做不到，虽然我可以写出

Instrument>>playNote:note
  ^self subclassResponsibility.

Instrument>>playChord:chord
  ^self subclassResponsibility.

但是他却不是一个接口，我可以很用

instrument = Instrument new.
instrument playNote: Note C.

来构造一个Instrument之后在它之上调用playNote方法，然而我会得到一个messageNotUnderstand的错误，Smalltalk和Ruby里没有Abstract的概念。也就是说abstract method，abstract class以及interface，都不是面向对象的概念（或者严格一些说，都不是面向对象的必须的概念），而是面向对象类型系统的概念。那么在Smalltalk里我们会怎么做呢？

Person>>playSoloOnInstrument:instrument
  instrument playNote: Note C;
             playNote: Note D;
             playNote: Note E.

Person>>playBackgroundOnInstrument:instrument
  instrument playChord: Chord C1;
                      playChord: Chord C1;
                      playChord: Chord C1;

对于playSoloOnInstrument:instrument，我们对于instrument的类型是有要求的，就是它必须能够接受playNote这个消息。当然这个类型需要是隐性，我也可以对等的写出静态面向对象的代码把这个隐性的类型显示的表示出来:

1interface Instrument {
2   Instrument playNote(Note note);  
3}

同样对于第二个方法我们也可以写出来:

1interface Instrument {
2   Instrument playChord(Note note);  
3}

如果我们需要多于一个的消息也是一样的，比如

Person>>playBWV996OnInstrument:instrument
   instrument playNote: Note C;
              playChord: Chord C;
              playNote: Note D.

同样这个时候隐性的类型需要就是

1interface Instrument {
2   Instrument playNote(Note note);  
3   Instrument playChord(Note note);  
4}

那么接口是什么呢？我给出一个不确切的说法，interface是一个消息的发送者(sender)和一个消息的接受者(reciver)间的一种类型的约定，也就是说在我看来interface的用处主要在细粒度的显式类型约定。我有一个同事，每次写代码都为一个Test Case所要测试的对象定义一个interface，每个interface都只有2-3个方法（lx同学夸你呢:D），这是很得interface之三味的用法。这种的做法对于在静态的面向对象系统的好处我们在继承里再论述。

至于老庄所说的接口是多继承的一种代替品，这只不过是世俗的看法，在静态类型的面向对象里，继承至少有2个语义:

1.实现继承，这个在Smalltalk，Ruby，C++里有，而在java里没有，C++里是通过private extends来实现的

1class SubClassA: private ImplementationParent {
2}

这也是C++里为数不多的subclass不是subtype的例子。

2.类型继承，这个在C++和java里有，而在smalltalk,ruby有却不明显。

类型继承的极致就是C++里的纯虚父类

1abstract class Parent {
2
3  public asbtract void method1() = 0;
4  public asbtract void method2() = 0;
5}

也就是java里的interface

1interface Parent {
2   void method1();
3   void method2();
4}

因此，也就明了了，所谓“面向接口编程”是以类型作为约定的编程。我觉得这点大家一定不陌生，面向接口的编程里interface都很小而且约定明确。但是要说明一点的是，这个东西和"面向抽象而不要面向具体编程"其实还不一样，所以这个东西也就仅仅能算是静态类型面向对象的一个惯用法，还到不了原则这么高。

1.重新学习了lambda演算。我的数学基础不及taowen等，费了一些时日仍不完全了然，目前大抵能对着R5RS后面的语义定义对一些简单的scheme程序进行lambda演算。
2.反复研究了几遍SICP。同时看了录像和书（感谢曹老师下的Video），自信对前二章半有些许认识书中未及，后二章半粗知大览尚不能发前人所未发之言。
3.学习了Smalltalk和Ruby，Duck Typing以及其他一些有关类型系统的东西。
4.回顾了一下面向对象语言的一些发展史，以史为鉴粗知一些兴替。
5.经日和taowen，老庄讨论语言、设计等等之类，每为一辨必穷我所知争发一言，所以知识可以迅速杂糅:D

经过种种之后，发现当初所谓鸣OO之丧钟，实在是言过其实。
--------------------------------------------------------------------------------------------------------------------------------------------------------------
第0 关于"面向对象"

既然要为人家敲丧钟，先要找对了苦主，不然岂不是白忙活了一场。什么是面向对象？这个问题太大，我们举一个很常见的例子：

interface Instrument {
   void playNote(Note note);
   void playChord(Chord chord);
}

abstrat class Keyboard implement Instrument {
  ..
}

class ClassicGuitar implements Instrument {
   .
}

class Piano extends Keyboard {
  ..
}

in person class

void playSolo(Instrument instrument) {
   instrument.playNote(AbsoluteNote.C1).playNote(AbsoluteNote.C2);
   
}

void playBackground(Instrument instrument) {
   instrument.playChord(Chord.C5).playChord(Chord.C9);
   
}


in some case

ClassicGuitar perez711= .
Piano pianoHere = .

vincent.playSolo(stenzel);
may.playBackground(pianoHere);

etc.

这个例子自然很不充分，不过继承啊，接口啊，多态啊，略举大概，尚可以作为一个讨论的例子。从这个例子里，我们发现有这样一个事实，就是Person类有两个方法

void playSolo(Instrument instrument);
void playBackground(Instrument instrument);

分别表示，需要一个类型为Instrument的对象instrument，然后对他进行相应的操作，而且，从概念上来讲，第一个方法，使演奏旋律的，也就是单音，而第二个方法是演奏和声的。那么，如果我有一个类

class GlassBottle {

   void playNote(Note note) {
      ..
   }
}

我们知道，玻璃瓶装了水也是可以发出声音，Mozart可是为玻璃瓶写过曲子的，而这里我们却不能

GlassBottle beerBottle = .
vincent.playSolo(beerBottle);

因为我们在构造Person类的时候，我们的play方法是依赖一个类型为Instrument的Object，换而言之，我们这里所谓的Object-Oriented其实称作Object-with-Type-Oriented的更合适，其实这类语言有一个专有名词，叫做static type object oriented。那Object-Oriented是不是就一定是Static Type Object Oriented的呢？不然，比如在Ruby里，我们可以写成：

class Person 
  def playSolo(thing)
     thing.playNote(Note.C1).playNot(Note.c2)
  end
  def playBackground(thing)
     thing.playChord(Chord.C5).playChord(Chord.C9)
  end
end

class Guitar
  def playNote(note)
    
  end
  def playChord(chord)
    
  end
end

class GlassBottle
  def playNote(note)
    
  end
end

然后就可以

perez711 = Guitar.new
vincent = Person.new
vincent.playSolo(perez711)

同样也可以

vincent.playSolo(GlassBottle.new)

在这里，类型可以推演也可以留到runtime检查，如果是推演的话，在playNote里，由于thing调用了playNote方法，所以传进来的对象必须要刻意接受playNote这个消息，于是Guitar和GlassBottle都是可以通过，因此我即可以演奏我的Perez 711，也可以敲玻璃瓶。这种方式叫做dynamic type。

那么static type和dynamic type区别在那呢？static type认为，class就是type，type就是class; subclass就是subtyping，subtyping就是subclass(其实这句不严谨，在c++里可以使得subclass不是subtyping，但是java里就没办法了);而dynamic type则认为类型和class没有关系，类型取决于一个对象能够接受的消息。

那么哪个才是面向对象之真貌呢？遗憾的说，static type并不是最初的面向对象。以对象作为模块化的单位，始自Simula 67。但是Simula 67并不是一个面向对象系统，以目前的观点来看，充其量是Object-based，第一个面向对象语言当推Smalltalk，Smalltalk是dynamic type的。不过Smalltalk不太流行，第一个大面积流行的面向对象语言是C++，C++是static type的，正如Lisp是第一个函数式编程语言，很多Lisp的特性被当作函数式语言的共有特性(比如表是最重要的数据结构，轻语法)一样，所以很多人以为面向对象就必然是static type（比如老庄和我）。对于面向对象的误解，80%来自C++。也就是说，80%来自于static type的面向对象系统。将static type面向对象归咎于整个面向对象，我辈实在是大而无当言过其实。

后面我再一一将老庄所言之OO不当之处加以说明

1class Order {
2
3  private List<OrderItem> items;
4
5  public List<OrderItem> getItems() {
6     
7  }
8}

在J2SE5里面，

 1class Order implements Iterable<OrderItem> {
 2
 3       private List<OrderItem> items;
 4
 5       public Iterator<OrderItem> iterator() {
 6               return items.iterator;
 7       }
 8
 9      public int getItemCount() {
10             
11      }
12      // and addItem removeItem and others
13}

就可以直接来处理，

1for (OrderItem item : order) {
2}

从某种程度上利用enhanced for的语法，来简化语法。

trade-off: 不适合多个details 聚合，适合于简单的moment-interval和moment-interval-details。

2. Annotate Description with @Embeddable, and the Thing it describe with @Entity

例子，Product和ProductDescription

 1@Embeddable
 2class ProductDescription {
 3  private String name;
 4  private String description;
 5  . and getters and setters
 6}
 7
 8@Entity(access = AccessType.FIELD)
 9class Product {
10  private ProdcutDescription description;
11}

在JSR220里，如果一个field是embeddable，而且对该field没有标注为@Transite,以及使用keyword transite,自动按Embedded处理，这一点是很方便的。

这个基本没发现trade-off


3. Avoid Database Primary Key in Domain Model Using @EmbeddableSuperclass

例子，在hibernate里，总是要给Domain加一个primary key，非常的不爽.
虽然也可以通过继承结构来避免，但是配置文件太多， JSR220里，通过自动处理的annotation ，可以节约很大的工作量。

 1@EmbeddableSuperclass
 2class DomainModel {
 3//  modeling your model here
 4}
 5
 6@Entity
 7class PersistentDomainModel extends DomainModel {
 8
 9   private long primaryKey;
10}

这个大家就一目了然了

4. Avoid Database Field in Domain Model Using @AttributeOverride


Annotation虽然简化了开发，但是仍然有一个问题，就是修改mapping的时候需要修改代码，这个很不好，而且影射的时候需要在domain里硬编码field
name，这个简直就是恶心，但是还是由办法避免的。

 1@EmbeddableSuperclass
 2class DomainModel {
 3//  modeling your model here
 4}
 5
 6
 7@Entity
 8@AttributeOverride(name="property", column=@Column(name="fieldName"))
 9class PersistentDomainModel extends DomainModel {
10
11   private long primaryKey;
12}

同样，通过继承来隔离技术和Domain，然后在子类里作部署相关的动作。然后把DomainModel和PersistentDomainModel 分包，针对DomainModel编程，就Ok了。这个时候Domain会异常的干净.....

5. Model Place as Factory

其实这个是一个通则，以前好像也讨论过。

1public interface Store {
2  Order newOrder();
3  // and others;
4}

基本上下午2个小时的成果就这么多，我是在尝试用JSR220 API代替以前我和limo写的那个珍珠商城订单部分得到的一些tips。总体而言，JSR220还是挺好的，我们可以很自然的运用一些模式和OO的手段还避免它的不足。同时上述做法在hibernate里也可以做，但是由于比较麻烦，大家一般还是做不到。JSR220里，正是通过它的毛病强迫我们这么做.....（汗），也算体现出约定了。

so, you think the consistent thing means a lot? But how do you think the gracious or elegant feeling mean to the real expressiveness of business requirements? We can see lisp is very successful in researching area because of the simplicity nature inside which is also true to Smalltalk. But why they aren't successful in biz world? I think that is the problem you should further study, "how can the consistent feeling mean something to our everyday programming life?".

我承认以前没有考虑到这个问题，因为我以为追求概念一致性是一种不言自明的天性。那么为什么要一致性很重要呢？我有这样一些想法。

1. 复杂性

概念不一致产生首先产生的一个恶果就是复杂性，这里我将举两个例子。

第一个关于Lisp的。Lisp本身具有一个很一致很简单的计算模型——λ 演算。在这个计算模型中，基本元素是函数，λ运算符，·运算符。语义也是简单明确的，lambda运算符提取出函数中的自由变量，然后再由apply对自由变量赋值。整个计算过程就是函数（符号）求值的过程。例如对于函数x + y，我们可以这样来求值。

((λx (λy . x + y)·3)·4)
=((λx. x+3)·4)
=4 + 3
=7

由于Lisp多少可以认为是λ 演算的一种实现，我们可以类似写出Lisp代码

(define f (lambda x (lambda y (+ x y))))
(apply (apply f 3) 4)

或者更加简单的写为

(define (f x y) (+ x y))
(f 3 4)

所有在Lisp中的程序，我们都可以用一种一致的概念来表达，就是符号求值，我们对一个符号应用一些值，然后这个符号完成计算并把结构返回给我们，在计算的过程中，符号对外部环境没有任何破坏和依赖。但是Lisp中引入了赋值，于是存在一些符号，不仅仅是来计算，同时他们还能改变环境。

(define (bad-f x y) 
  (begin 
     (set! z 5)
     (+ x y)))

这个函数不仅仅求x + y的值，同时修改了符号Z的值。赋值的引入破坏了函数只求值而不影响环境这个概念的一致性。于是我们不得不寻找一个更加复杂的也更加混乱的计算模型，来代替简单优雅的λ 演算。于是不一致的概念带来了思维上的复杂性(不过Lisp中的概念不一致除了产生了复杂之外，还激发了人们对于简单计算模型的向往从而产生了函数式编程风格，这也是我最爱的编程风格之一)。

概念不一致带来的复杂性距离我们最近的应该是Java中的简单类型，Java本身是一个单根的面向对象语言，从概念上讲一切都应该是对象，而且由于性能考虑而出现的简单类型，引入了代数性的世界观的同时，破坏了面向对象的一致概念。Java中虽然有包装类来做补偿，但是仍然不能弥补概念上的断裂。我们可以用

1new Integer(3)

来代表对象概念中的3，但是

3 + 4 * 5

不能对等的翻译为:

1new Integer(3) + new Integer(4) * new Integer(5)

简单类型具有的运算符和对象类型的消息发送概念上是不一致的。虽然我们可以在Java 5中使用上述的代码，但是Java 5的Auto-Boxing更多的把对象类型当作简单类型进行数据运算，而不是像C++中的运算符重载一样把数据运算当作一种特殊消息传递，虽然语法上有相似的功能，但是概念上大异其趣，对于我这个OO分子而言，Java 5的Auto-Boxing实在是恶心到不行。同时简单类型和对象类型在赋值语义和存储模型上也存在很大的不一致，这种不一致性在使用Collection API的时候带来了一些复杂度。（还记得Commons Collection里那些Primitive Collection吧？）

2.副作用

概念不一致产生的第二个恶果就是副作用，我大概想了一下都有哪些可能的副作用，结果让我很寒，我能想到的副作用，大多数是由于在另一种模型中引入了冯语言的因素从而造成了概念上的不一致而引起的。其中最为人知的....还是赋值在函数式编程中的副作用...这个在函数式编程社区有很广泛的讨论，我只说一点，为什么命令语言是有害的。

冯语言或者说命令式语言主要用于刻画对计算机操作的序列，并不关心序列的内在关系。也就是说，我们可以把一些完全没有联系的指令写在一起。因此冯语言在语义上毫无建树，同时在抽象上也止步于子程序（一砣指令和另一砣指令）。冯语言具有很强的时间耦合性在存储上也强烈的倾向于线性存储。目前大多数难处理的问题，可以归结为计算模型和操作语义的不一致，甚至有些学者认为是冯结构严重制约了计算机的发展。因此冯语言被函数社区看作一个很危险的副作用，极力避免之。

概念的不一致产生的副作用在混血的OO语言中也很明显，尤其是在命令式语言中加入面向对象机制，而且使用面向对象作为类型系统的扩展，使用过程式的方法来控制流程。过程和对象的不一致本身就给了程序员一种暗示，你可以使用对象技术来构造类型系统，然后使用过程的方法来操作他。明显的副作用们很容易使用过程化程序，从而使得对象带来的好处被很大的削弱了（当然我们有重构来弥补这个错误），比如下面一个例子,我们很容易从写出下面的代码：

1if (order.getState() == Order.CANCEL)
2   do something for cancel;
3else if(order.getState() == Order.PAID)
4   do something for paid;
5else if(order.getState() == Order.DELIVERY)
6   do something for delivery

而不是

 1public abstract OrderState {
 2
 3   protected Order _order;
 4   
 5   protected OrderState(Order order){
 6      _order = order;
 7   }
 8    
 9   public abstract void handler();
10}
11
12class CancelState extends OrderState {
13
14   public void handler() {
15      do something for cancel;
16   }
17}
18
19order.getState().handle();

因为存在过程性的关键字if, while,处于方便的考虑，我们会写出第一种风格的代码，而考虑到易于维护，我们应该写第二种风格的代码。存在两种不一致的书写代码的风格，这个时候，副作用取决于使用的语言OO的程度，比如在C++里更容易写出第一种风格的代码，而在Ruby和Smalltalk中，更容易写出第二种风格的代码。

3.递归的构造软件

这个虽然跟概念一致有关，但是一个更大的主题，待续吧。

4.优雅，美感和无名品质

概念的一致性会产生一种优雅的美感，我觉得我们都有这种感觉，如果我们能用一种一致的容易理解且统一的方式来处理多种不同的复杂的问题，那么我们就会觉得这种方法很优雅，也很具有美感。类比物理中的牛顿定律，开普勒定律，麦克斯韦方程，都是这种简单一致而解决复杂问题的完美示例。我们更容易感觉到一致的感念产生的美感，而不一致的概念往往很难令我欣赏。或许无名品质是我对一致的概念的一种模糊的审美吧。

我大抵能想到的就这么多，不知小tao是否满意我的答卷。

Boolean>>ifTrue: aBlock
  self subclassResponsibility

Boolean>>ifFalse: aBlock
  self subclassResponsibility

True>>ifTrue: aBlock
  ^aBlock value.

True>>ifFalse: aBlock
  ^nil.

False>>ifTrue: aBlock
  ^nil.

False>>ifFalse: aBlock
  ^aBlock value.

然后就可以，

4 〉3 ifTrue: [Transcript show: 'Hello']

因为在Smalltalk里，一切皆对象且从左到右求值，于是4 > 3 返回true，true是类True的唯一实例，然后就可以对它发送消息，ifTrue:，于是调用了^aBlock value.来对传进去的BlockClosure求值。

下面是类似的java的类似代码。

 1public class abstract Boolean {
 2   public static final TRUE = new True();
 3   public static final FALSE = new False();
 4
 5   public abstract Object ifTrue(Block aBlock);
 6   public abstract Object ifFalse(Block aBlock);
 7}
 8
 9class True extends Boolean {
10
11   public Object ifTrue(Block aBlock) {
12       return aBlock.execute();
13   }
14
15   public Object ifFalse(Block aBlock) {
16       return null;
17   }
18}
19
20class False extends Boolean {
21
22   public Object ifTrue(Block aBlock) {
23       return null;
24   }
25
26   public Object ifFalse(Block aBlock) {
27       return aBlock.execute();       
28   }
29}
30

4 〉3 ifTrue: [Transcript show: 'Hello']就可以对应翻译为:

1Boolean condition = new Integer(4).isGreaterThan(new Integer(3));
2condition.ifTrue(new BlockClosure() {
3   public Object execite() {
4      System.out.println("Hello");
5      return null;
6   }
7});
8
9

这个看似简单的应用，却带来了两个有深刻影响的性质。

第一，由于if,else等结构不再是预定义的语法了，而与我们自己写的代码一样，属于莫一个类的特定消息，那么也就意味着，我们可以像ifTrue一样，定义自己的分支结构。
比如
   aUser ifNotRegistered: [ do redirect to register page ]
         ifExpired: [ do redirect to active page ]

在不考虑性能优化的前提下，Smalltalk认为和
   4 >3 ifTrue: [do something]
        ifFalse: [do somthing]

是具有一样的语义的。并不因为Boolean属于Kernel就有什么不同。因此控制结构也属于一个可编程的因素，这就是Smalltalk的轻语法特性。

第二，在简单的语法和完全的面向对象语义中，构造与冯诺依曼式语言完全等价的能力（这种能力在语法上表现为赋值，分支，迭代和子程序调用），于是我们可以完全用一致的面向对象的方法来构造软件。

很长一段时间以来，我都认为面向对象方法论是在命令式的冯诺依曼式语言的基础上，通过引入类型系统然后修修补补的得到的，由于冯诺依曼语言式的语言是面向操作层面上的，只是为了更好的刻画操作计算的一个命令的序列，因此冯语言不可避免的具有不完备的语义，混乱的抽象表达以及等等一系列的问题。作为冯语言的一个大补丁的面向对象方法，我也想当然的以为他虽然有了些进步，但是基础问题上面还是不能避免的，加之面向对象缺乏一种一致的构造方法，很多时候我们不得不回归到命令式或者过程式的方法来构造系统，从而破坏掉一种一致清晰的思路，在过程和对象之间不住地权衡（比如Domain Model之争），这个让人非常的不爽。在尝试了一些面向对象语言之后（我是在95年接触C++的时候开始了解面向对象的，而后主要使用Java做为开发语言），我发现这个问题是很难避免，于是我断言这是面向对象技术本身的问题，现在看来不过自己所学有限，没有真正用过纯面向对象语言而已，汗颜得很啊。这里向面向对象方法道个歉，嘿嘿。