日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時(shí)間：8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
淺談Java7的閉包與Lambda表達(dá)式之優(yōu)劣

前幾天Oracle推出了Java 7官方的閉包與Lambda表達(dá)式的第一個(gè)實(shí)現(xiàn)，這基本上也是最終在正式版中的樣式了?？戳诉@個(gè)實(shí)現(xiàn)之后，我的第一感覺便是“丑”，當(dāng)然不排除這是因?yàn)榭磻T了其他語言中實(shí)現(xiàn)的緣故。后來再仔細(xì)看了看又想了想，發(fā)現(xiàn)Java 7的實(shí)現(xiàn)也并非毫無可取之處，但似乎又感到某些做法上有一些問題。總之整個(gè)過程頗為有趣，決定將我的想法記錄下來，希望可以吸引人來一起討論一下。

為響水等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計(jì)制作服務(wù)，及響水網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為網(wǎng)站建設(shè)、成都網(wǎng)站建設(shè)、響水網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會(huì)得到認(rèn)可，從而選擇與我們長期合作。這樣，我們也可以走得更遠(yuǎn)！

Java 7中的Lambda表達(dá)式

Java 7中的Lambda表達(dá)式有兩種形式，首先是第一種：

 
 
 
    
  
  
  
  1. #int() func1 = #()(3); // "func1.()" returns 3  
    2. 
  
  
  
  2. #int(int) func2 = #(int x)(x + 1); // "func2.(3)" returns 4  
    3. 
  
  
  
  3. #int(int, int) func3 = #(int x, int y)(x - y); // "func3.(5, 3)" returns 2 
    4.

然后是第二種，含義與上面等價(jià)：

 
 
 
    
  
  
  
  1. #int() func1 = #(){ return 3; };  
    2. 
  
  
  
  2. #int(int) func2 = #(int x){ return x + 1; };  
    3. 
  
  
  
  3. #int(int, int) func3 = #(int x, int y){ return x – y; }; 
    4.

如果Lambda的body是“單個(gè)表達(dá)式”的話，便可以使用“小括號”，并省去最后的return關(guān)鍵字；如果body中需要包含多條語句的話，則必須使用“大括號”，而大括號內(nèi)部可以包含多條語句，就像一個(gè)普通的方法體一樣。這兩種寫法在C#中也有對應(yīng)物，如在“單個(gè)表達(dá)式”的情況下：

 
 
 
    
  
  
  
  1. // C#  
    2. 
  
  
  
  2. Func func1 = () => 3; // "func1()" returns 3  
    3. 
  
  
  
  3. Func func2 = x => x + 1; // "func2(3)" returns 4   
    4. 
  
  
  
  4. Func func3 = (x, y) => x - y; // "func3(5, 3)" returns 2  
    5.

第二種，即多條語句：

 
 
 
    
  
  
  
  1. // C#  
    2. 
  
  
  
  2. Func func1 = () => { return 3; };  
    3. 
  
  
  
  3. Func func2 = x => { return x + 1; };  
    4. 
  
  
  
  4. Func func3 = (x, y) => { return x – y; };  
    5. 
  
  
  
  5.  
    6.

Java和C#的Lambda表達(dá)式都由兩部分組成：“參數(shù)列表”和“表達(dá)式體”，但是它們有如下區(qū)別：

◆在Java中參數(shù)列表和表達(dá)式體之間沒有分隔符號，而C#使用“=>”分隔。

◆對于“單個(gè)表達(dá)式”的Lambda來說，C#可以無需使用括號包含表達(dá)式體，而Java必須使用小括號。

◆如果只有單個(gè)參數(shù)，那么C#的參數(shù)列表可以省去小括號，而Java必須保留。

◆C#對參數(shù)列表會(huì)進(jìn)行“類型推斷”，而Java必須寫清參數(shù)類型。

這些區(qū)別說大可大，說小可小，但是Java語言的設(shè)計(jì)的確讓我感覺較C#為“丑”，這可能是個(gè)人主觀因素，但我認(rèn)為也不盡然。例如，如果我們需要對一個(gè)用戶對象數(shù)組按照“年齡”進(jìn)行排序，在C#里可以寫作：

 
 
 
    
  
  
  
  1. // C#  
    2. 
  
  
  
  2. users.Sort(u => u.Age);  
    3. 
  
  
  
  3.  
    4.

而在Java中則必須寫為：

 
 
 
    
  
  
  
  1. Arrays.sort(users, #(User u)(u.Age));  
    2. 
  
  
  
  2.  
    3. 
  
  
  
  3.    
    4.

這句C#代碼語義清晰：按照“u的Age進(jìn)行排序”，而在Java代碼中便顯得比較累贅，語義似乎也不夠清晰。Anders在設(shè)計(jì)C#語法的時(shí)候非常注重“聲明式”代碼，由此可見一斑。此外，我不明白為什么Java選擇不對參數(shù)進(jìn)行類型推斷，在我看來這對于寫出優(yōu)雅代碼十分重要（關(guān)于這點(diǎn)，在“Why Java Sucks and C# Rocks”系列中會(huì)有更詳細(xì)的討論）。不過Java也不是沒有“推斷”，例如從上面的代碼片斷中可以得知，Java對于Lambda表達(dá)式的返回值還是進(jìn)行了類型推斷。事實(shí)上，Java還推斷了“異常類型”，這點(diǎn)稍后會(huì)有更多討論。

當(dāng)然，Java中可以“無中生有”地定義“匿名函數(shù)類型”（這點(diǎn)和VB.NET相對更為接近），而不需要像C#一樣需要基于特定的“委托類型”，顯得更為靈活。

#p#

SAM類型支持及閉包

SAM的全稱是Single Abstract Method，如果一個(gè)類型為SAM類型，則意味著它 1) 是抽象類型（即接口或抽象類），且 2) 只有一個(gè)未實(shí)現(xiàn)的方法。例如這樣一個(gè)Java接口便是個(gè)SAM類型：

 
 
 
    
  
  
  
  1. public interface Func {  
    2. 
  
  
  
  2.     R invoke(T arg);  
    3. 
  
  
  
  3. }  
    4. 
  
  
  
  4.  
    5. 
  
  
  
  5.    
    6. 
  
  
  
  6.  
    7.

于是我們便可以：

 
 
 
    
  
  
  
  1. Func[] array = new Func[10];  
    2. 
  
  
  
  2. for (int i = 0; i < array.length; i++) {  
    3. 
  
  
  
  3.     final int temp = i;  
    4. 
  
  
  
  4.     array[i] = #(int x)(x + temp);  
    5. 
  
  
  
  5. }  
    6. 
  
  
  
  6.  
    7. 
  
  
  
  7.  
    8. 
  
  
  
  8.  
    9.

可見，我們使用Lambda表達(dá)式創(chuàng)建了Func接口的實(shí)例，這點(diǎn)是C#所不具備的。這點(diǎn)十分關(guān)鍵，因?yàn)樵贘ava類庫中已經(jīng)有相當(dāng)多的代碼使用了SAM類型。不過我發(fā)現(xiàn)，在某些使用SAM的方式下似乎會(huì)產(chǎn)生一些“歧義”，例如這段代碼：

 
 
 
    
  
  
  
  1. public class MyClass {  
    2. 
  
  
  
  2.     @Override  
    3. 
  
  
  
  3.     public int hashCode() {  
    4. 
  
  
  
  4.         throw new RuntimeException();  
    5. 
  
  
  
  5.     }  
    6. 
  
  
  
  6.  
    7. 
  
  
  
  7.     public void MyMethod() {  
    8. 
  
  
  
  8.         Func func = #(int x)(x * hashCode());  
    9. 
  
  
  
  9.         int r = func.invoke(5); // throw or not?  
    10. 
  
  
  
  10.     }  
    11. 
  
  
  
  11. }  
    12. 
  
  
  
  12.  
    13. 
  
  
  
  13.    
    14.

在這里我們覆蓋（override）了MyClass的hashCode方法，使它拋出RuntimeException，那么在調(diào)用MyMethod中定義的func1對象時(shí)會(huì)不會(huì)拋出異常？答案是否定的，因?yàn)樵谶@個(gè)Lambda表達(dá)式中，隱藏的“this引用”代表了func對象，調(diào)用它的hashCode不會(huì)拋出RuntimeException。那么，假如我們要調(diào)用MyClass的hashCode怎么辦？那就稍微有些麻煩了：

 
 
 
    
  
  
  
  1. Func func = #(int x)(x * MyClass.this.hashCode());  
    2. 
  
  
  
  2.  
    3. 
  
  
  
  3.    
    4. 
  
  
  
  4.  
    5.

不過從另一段示例代碼上看：

 
 
 
    
  
  
  
  1. public class MyClass {  
    2. 
  
  
  
  2.  
    3. 
  
  
  
  3.     public int n = 3;  
    4. 
  
  
  
  4.  
    5. 
  
  
  
  5.     public void MyMethod() {  
    6. 
  
  
  
  6.         Func func = #(int x)(x + n);  
    7. 
  
  
  
  7.         int r = func.invoke(5); // 8  
    8. 
  
  
  
  8.     }  
    9. 
  
  
  
  9. }  
    10.

由于Func對象上沒有n，因此這里的n便是MyClass類里定義的n成員了。因此，Java的閉包并非不會(huì)捕獲字面上下文里的成員，只是在SAM類型的情況下，字面范圍內(nèi)（lexical scope）成員的優(yōu)先級會(huì)低于目標(biāo)抽象類型的成員。

總體來說，對于SAM類型的支持上，我認(rèn)為Java是有可取之處的，只是我始終認(rèn)為這個(gè)做法會(huì)產(chǎn)生歧義，因?yàn)槲矣∠笾衅渌Z言里的Lambda表達(dá)式似乎都是捕獲字面上下文的（當(dāng)然它們可能也沒有SAM支持）。但是，如何在“歧義”和“優(yōu)雅”之間做出平衡，我一時(shí)也找不到令人滿意的答案。

硬傷：Checked Exception

Java相當(dāng)于其他常見語言有一個(gè)特別之處，那就是Checked Exception。Checked Exception意味著每個(gè)方法要標(biāo)明自己會(huì)拋出哪些異常類型（RuntimeException及其子類除外），這也是方法契約的一部分，編譯器會(huì)強(qiáng)制程序員寫出滿足異常契約的代碼。例如某個(gè)類庫中定義了這樣一個(gè)方法：

 
 
 
    
  
  
  
  1. public void myMethod() throws AException, BException  
    2. 
  
  
  
  2.  
    3. 
  
  
  
  3.    
    4.

其中throws后面標(biāo)注的便是myMethod可能會(huì)拋出的異常。于是如果我們要寫一個(gè)方法去調(diào)用myMethod，則可能是：

 
 
 
    
  
  
  
  1. public void myMethodCaller() throws AException {  
    2. 
  
  
  
  2.     try {  
    3. 
  
  
  
  3.         myMethod();  
    4. 
  
  
  
  4.     } catch (BException ex) {  
    5. 
  
  
  
  5.         throw new AException(ex);  
    6. 
  
  
  
  6.     }  
    7. 
  
  
  
  7. }  
    8. 
  
  
  
  8.  
    9. 
  
  
  
  9.    
    10.

當(dāng)我們寫一個(gè)方法A去調(diào)用方法B時(shí)，我們要么在方法A中使用try...catch捕獲B拋出的方法，要么在方法A的簽名中標(biāo)記“會(huì)拋出同樣的異?！薄Ｈ缟厦娴膍yMethodCaller方法，便在內(nèi)部處理了BException異常，而只會(huì)對外拋出AException。Java便使用這種方法嚴(yán)格限制了類庫的異常信息。

Checked Exception是一個(gè)有爭議的特性。它對于編寫出高質(zhì)量的代碼非常重要，因?yàn)樵谀男┣闆r拋出異常其實(shí)都是方法契約的一部分（不僅僅是簽名或返回值的問題），應(yīng)該嚴(yán)格遵守，在類庫升級時(shí)也不能破壞，否則便會(huì)產(chǎn)生兼容性的問題。例如，您關(guān)注MSDN里的文檔時(shí)，就會(huì)看到異常的描述信息，只不過這是靠“文檔”記錄的，而Java則是強(qiáng)制在代碼中的；但是，從另一個(gè)角度說，Checked Exception讓代碼編寫變得非常麻煩，這導(dǎo)致的一個(gè)情況便是許多人在寫代碼時(shí)，自定義的異常全都是RuntimeException（因?yàn)椴恍枰獦?biāo)記），每個(gè)方法也都是throws Exception的（這樣代碼中就不需要try...catch了），此時(shí)Checked Exception特性也基本形同虛設(shè)，除了造成麻煩以外幾乎沒有帶來任何好處。

我之前常說：一個(gè)特性如果要被人廣泛接受，那它一定要足夠好用?，F(xiàn)在如Scala和Grovvy等為Java設(shè)計(jì)的語言中都放棄了Checked Exception，這也算是從側(cè)面印證了Checked Exception的尷尬境地吧。

#p#

而Checked Exception對于如今Lambda或閉包來說，在我看來更像是一種硬傷。為什么這么說？舉個(gè)例子吧，假如有這么一個(gè)map方法，可以把一個(gè)數(shù)組映射成另一個(gè)類型數(shù)組：

 
 
 
    
  
  
  
  1. public R[] map(T[] array, Func mapper) { ... }  
    2. 
  
  
  
  2.  
    3. 
  
  
  
  3.    
    4.

好，那么比如這樣一個(gè)需求：給定一個(gè)字符串?dāng)?shù)組，保存著文件名，要求獲得它的標(biāo)準(zhǔn)路徑。從表面上看來，我們可以這樣寫：

 
 
 
    
  
  
  
  1. map(files, #(String f)(new File(f).getCanonicalPath())  
    2. 
  
  
  
  2.  
    3. 
  
  
  
  3.    
    4.

但事實(shí)上，這么做無法編譯通過。為什么？因?yàn)間etCanonicalPath方法會(huì)拋出IOException，我們在調(diào)用時(shí)必須顯式地使用try...catch進(jìn)行處理。那么這段代碼該怎么寫？還真沒法寫。如果沒有Checked Exception的話（如C#），我們還可以這么做（處理第一個(gè)拋出的IOException）：

 
 
 
    
  
  
  
  1. public interface FuncThrowsIOException {  
    2. 
  
  
  
  2.     R invoke(T arg) throws IOException;  
    3. 
  
  
  
  3. }  
    4. 
  
  
  
  4.  
    5.

 

 但是，如果我們要寫出之前那種“漂亮”的寫法，就不能使用Func而必須是這樣的接口類型：

 
 
 
    
  
  
  
  1. public interface FuncThrowsIOException {  
    2. 
  
  
  
  2.     R invoke(T arg) throws IOException;  
    3. 
  
  
  
  3. }  
    4. 
  
  
  
  4.  
    5.

或者是這樣的“匿名函數(shù)類型”：

#String(String)(throws IOException) // toCanonicalPath = #(String f)(new File(f).getCanonicalPath())
但是，作為Lambda和閉包的常用場景，如map，filter，fold等“函數(shù)式”元素，是不可能為某種特定的“異常類型”而設(shè)計(jì)的——異常類型千變?nèi)f化，難道這也要用throws Exception來進(jìn)行“統(tǒng)一處理”嗎？Java雖然已經(jīng)支持對異常類型的“推斷”，但Checked Exception還是對Lambda和閉包的適用性造成了很大影響。

因此，我認(rèn)為Checked Exception是一個(gè)“硬傷”。

其他

Java的Lambda和閉包還有一些特性，例如參數(shù)的“泛化”：

 
 
 
    
  
  
  
  1. #boolean(Integer) f = #(Number n)(n.intValue() > 0);  
    2. 
  
  
  
  2.  
    3.

由于Number是Integer的基類，因此我們可以使用Number來構(gòu)造一個(gè)接受Integer參數(shù)的匿名函數(shù)類型。由于示例較少，我還不清楚這個(gè)特性的具體使用場景和意義所在——不過我猜想，在Java中可能允許這樣做吧：

 
 
 
    
  
  
  
  1. #boolean(Number) f = #(Number n)(n.intValue() > 0);  
    2. 
  
  
  
  2. #boolean(Integer) ff1 = f; // cast implicitly or explicitly  
    3. 
  
  
  
  3.  
    4.

此外還有一些特性，例如與MethodHandle類型的轉(zhuǎn)化，我就沒有特別的看法了。

趙劼，網(wǎng)名老趙，洋名Jeffrey Zhao，目前就職于盛大創(chuàng)新院產(chǎn)品開發(fā)部，研究員。InfoQ中文站編輯，多次受邀于微軟TechED，MSDN WebCast及各微軟官方或社區(qū)會(huì)議中擔(dān)任技術(shù)議題講師。

原文地址：http://blog.zhaojie.me/2010/06/first-version-of-lambda-and-closures-in-java-7.html


新聞名稱：淺談Java7的閉包與Lambda表達(dá)式之優(yōu)劣
網(wǎng)頁鏈接：http://www.dlmjj.cn/article/ccdjcjc.html