程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> JAVA編程 >> 關於JAVA >> 淺談Java 7的閉包與Lambda表達式之優劣

淺談Java 7的閉包與Lambda表達式之優劣

編輯:關於JAVA

前幾天Oracle推出了Java 7官方的閉包與Lambda表達式的第一個實現,這基本上也是最終在正式版中 的樣式了。看了這個實現之後,我的第一感覺便是“丑”,當然不排除這是因為看慣了其他語言中實現的 緣故。後來再仔細看了看又想了想,發現Java 7的實現也並非毫無可取之處,但似乎又感到某些做法上有 一些問題。總之整個過程頗為有趣,決定將我的想法記錄下來,希望可以吸引人來一起討論一下。

Java 7中的Lambda表達式

Java 7中的Lambda表達式有兩種形式,首先是第一種:

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

然後是第二種,含義與上面等價:

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

如果Lambda的body是“單個表達式”的話,便可以使用“小括號”,並省去最後的return關鍵字;如 果body中需要包含多條語句的話,則必須使用“大括號”,而大括號內部可以包含多條語句,就像一個普 通的方法體一樣。這兩種寫法在C#中也有對應物,如在“單個表達式”的情況下:

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

第二種,即多條語句:

// C#
Func<int> func1 = () => { return 3; };
Func<int, int> func2 = x => { return x + 1; };
Func<int, int, int> func3 = (x, y) => { return x – y; };

Java和C#的Lambda表達式都由兩部分組成:“參數列表”和“表達式體”,但是它們有如下區別:

在Java中參數列表和表達式體之間沒有分隔符號,而C#使用“=>”分隔。

對於“單個表達式”的Lambda來說,C#可以無需使用括號包含表達式體,而Java必須使用小括號。

如果只有單個參數,那麼C#的參數列表可以省去小括號,而Java必須保留。

C#對參數列表會進行“類型推斷”,而Java必須寫清參數類型。

這些區別說大可大,說小可小,但是Java語言的設計的確讓我感覺較C#為“丑”,這可能是個人主觀 因素,但我認為也不盡然。例如,如果我們需要對一個用戶對象數組按照“年齡”進行排序,在C#裡可以 寫作:

// C#
users.Sort(u => u.Age);

而在Java中則必須寫為:

Arrays.sort(users, #(User u)(u.Age));

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

當然,Java中可以“無中生有”地定義“匿名函數類型”(這點和VB.NET相對更為接近),而不需要 像C#一樣需要基於特定的“委托類型”,顯得更為靈活。

SAM類型支持及閉包

SAM的全稱是Single Abstract Method,如果一個類型為SAM類型,則意味著它 1) 是抽象類型(即接 口或抽象類),且 2) 只有一個未實現的方法。例如這樣一個Java接口便是個SAM類型:

public interface Func<T, R> {
   R invoke(T arg);
}

於是我們便可以:

Func<int, int>[] array = new Func<int, int>[10];
for (int i = 0; i < array.length; i++) {
   final int temp = i;
   array[i] = #(int x)(x + temp);
}

可見,我們使用Lambda表達式創建了Func接口的實例,這點是C#所不具備的。這點十分關鍵,因為在 Java類庫中已經有相當多的代碼使用了SAM類型。不過我發現,在某些使用SAM的方式下似乎會產生一些“ 歧義”,例如這段代碼:

public class MyClass {
   @Override
   public int hashCode() {
     throw new RuntimeException();
   }

   public void MyMethod() {
     Func<int, int> func = #(int x)(x * hashCode());
     int r = func.invoke(5); // throw or not?
   }
}

在這裡我們覆蓋(override)了MyClass的hashCode方法,使它拋出RuntimeException,那麼在調用 MyMethod中定義的func1對象時會不會拋出異常?答案是否定的,因為在這個Lambda表達式中,隱藏的 “this引用”代表了func對象,調用它的hashCode不會拋出RuntimeException。那麼,假如我們要調用 MyClass的hashCode怎麼辦?那就稍微有些麻煩了:

Func<int, int> func = #(int x)(x * MyClass.this.hashCode ());

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

public class MyClass {

   public int n = 3;

   public void MyMethod() {
     Func<int, int> func = #(int x)(x + n);
     int r = func.invoke(5); // 8
   }
}

由於Func對象上沒有n,因此這裡的n便是MyClass類裡定義的n成員了。因此,Java的閉包並非不會捕 獲字面上下文裡的成員,只是在SAM類型的情況下,字面范圍內(lexical scope)成員的優先級會低於目 標抽象類型的成員。

總體來說,對於SAM類型的支持上,我認為Java是有可取之處的,只是我始終認為這個做法會產生歧義 ,因為我印象中其他語言裡的Lambda表達式似乎都是捕獲字面上下文的(當然它們可能也沒有SAM支持) 。但是,如何在“歧義”和“優雅”之間做出平衡,我一時也找不到令人滿意的答案。

硬傷:Checked Exception

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

public void myMethod() throws AException, BException

其中throws後面標注的便是myMethod可能會拋出的異常。於是如果我們要寫一個方法去調用myMethod ,則可能是:

public void myMethodCaller() throws AException {
   try {
     myMethod();
   } catch (BException ex) {
     throw new AException(ex);
   }
}

當我們寫一個方法A去調用方法B時,我們要麼在方法A中使用try...catch捕獲B拋出的方法,要麼在方 法A的簽名中標記“會拋出同樣的異常”。如上面的myMethodCaller方法,便在內部處理了BException異 常,而只會對外拋出AException。Java便使用這種方法嚴格限制了類庫的異常信息。

Checked Exception是一個有爭議的特性。它對於編寫出高質量的代碼非常重要,因為在哪些情況拋出 異常其實都是方法契約的一部分(不僅僅是簽名或返回值的問題),應該嚴格遵守,在類庫升級時也不能 破壞,否則便會產生兼容性的問題。例如,您關注MSDN裡的文檔時,就會看到異常的描述信息,只不過這 是靠“文檔”記錄的,而Java則是強制在代碼中的;但是,從另一個角度說,Checked Exception讓代碼 編寫變得非常麻煩,這導致的一個情況便是許多人在寫代碼時,自定義的異常全都是RuntimeException( 因為不需要標記),每個方法也都是throws Exception的(這樣代碼中就不需要try...catch了),此時 Checked Exception特性也基本形同虛設,除了造成麻煩以外幾乎沒有帶來任何好處。

我之前常說:一個特性如果要被人廣泛接受,那它一定要足夠好用。現在如Scala和Grovvy等為Java設 計的語言中都放棄了Checked Exception,這也算是從側面印證了Checked Exception的尴尬境地吧。

而Checked Exception對於如今Lambda或閉包來說,在我看來更像是一種硬傷。為什麼這麼說?舉個例 子吧,假如有這麼一個map方法,可以把一個數組映射成另一個類型數組:

public R[] map(T[] array, Func<T, R> mapper) { ... }

好,那麼比如這樣一個需求:給定一個字符串數組,保存著文件名,要求獲得它的標准路徑。從表面 上看來,我們可以這樣寫:

map(files, #(String f)(new File(f).getCanonicalPath())

但事實上,這麼做無法編譯通過。為什麼?因為getCanonicalPath方法會拋出IOException,我們在調 用時必須顯式地使用 try...catch進行處理。那麼這段代碼該怎麼寫?還真沒法寫。如果沒有Checked Exception的話(如C#),我們還可以這麼做(處理第一個拋出的IOException):

try {
   map(files, #(String f)(new File(f).getCanonicalPath())
catch (IOException ex) {
   ... 
}

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

public interface FuncThrowsIOException<T, R> {
   R invoke(T arg) throws IOException;
}

或者是這樣的“匿名函數類型”:

#String(String)(throws IOException) // toCanonicalPath = #(String f)(new  File(f).getCanonicalPath())

但是,作為Lambda和閉包的常用場景,如map,filter,fold等“函數式”元素,是不可能為某種特定 的“異常類型”而設計的——異常類型千變萬化,難道這也要用throws Exception來進行“統一處理”嗎 ?Java雖然已經支持對異常類型的“推斷”,但Checked Exception還是對Lambda和閉包的適用性造成了 很大影響。

因此,我認為Checked Exception是一個“硬傷”。

其他

Java的Lambda和閉包還有一些特性,例如參數的“泛化”:

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

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

#boolean(Number) f = #(Number n)(n.intValue() > 0);
#boolean(Integer) f1 = f; // cast implicitly or explicitly

此外還有一些特性,例如與MethodHandle類型的轉化,我就沒有特別的看法了。

文章來源:http://blog.zhaojie.me/2010/06/first-version-of-lambda-and-closures-in-java- 7.html

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved