跨越邊界: Java 模型以外的類型策略

下一頁 1 2 

　　 
　　當談到 Java 語言的類型方法時，Java 社區分為兩大陣營。一些人喜歡編譯時錯誤檢查，更好的安全性，以及改善的工具 —— 這些都是靜態類型所能提供的特性。而另一些人則偏愛更動態的類型體驗。

這一次在 跨越邊界 中，您將看到兩種高生產力的非 Java 語言所使用的一些截然不同的類型策略，并發現在 Java 編程中提高類型靈活性的一些方法。

　　在對任何編程語言的討論中，爭議較大的一個問題就是類型模型。類型決定可以使用哪些種類的工具，并影響到應用程序的設計。很多開發人員將類型與生產率或可維護性聯系起來（我就是其中的一個）。典型的 Java 開發人員通常都特別樂于維護 Java 語言的類型模型的地位，強調 Java 語言可采用更好的開發工具，在編譯時捕捉某些種類的 bug（例如類型不兼容和拼寫錯誤），以及性能等方面的優勢。

　　如果您想理解一種新的編程語言，甚至一系列語言，那么通常應該從類型策略著手。在本文中，您將看到 Java 之外的一些語言中的類型模型。我首先簡要介紹任何語言設計者在類型模型中必須考慮的一些決策，著重介紹靜態類型和動態類型的一些不同的決策。我將展示一些不同極端的例子 —— Objective Caml 中的靜態類型和 Ruby 中的動態類型。我還將談到 Java 語言的類型限制，以及如何突破 Java 類型的限制快速編程。

　　類型策略

　　至少可以從三個角度來看待類型：

　　靜態類型還是動態類型，這取決于何時 實施類型模型。靜態類型語言在編譯時實施類型。而動態類型語言通?；谝粋€對象的特征在運行時實施類型。

　　強類型還是弱類型，這取決于如何 實施類型模型。強類型嚴格地實施類型，如果發現有違反類型規則的情況，則會拋出運行時或編譯時錯誤。而弱類型則留有更多的余地。極端情況下，弱類型語言（例如 Assembler）允許將任意數據類型賦給另一種類型（不管這種賦值是否有意義）。靜態類型的語言既可以有強類型，也可以有弱類型；而動態類型系統通常是強類型的，但也不完全是。

　　顯式類型還是隱式類型，這取決于語言如何確定一個給定對象的類型。顯式類型語言要求聲明每個變量和每個函數參數。而隱式類型語言則根據語言中的語法和結構線索來確定對象的類型。靜態類型語言通常是顯式類型的，但也不完全是；而動態類型語言幾乎都是隱式類型的。

　　下面兩個例子很好地闡釋了其中兩個角度的內涵。假設您編譯下面這段 Java 代碼：

clearcase/" target="_blank" >cccccc width="90%" align=center bgColor=#e1e1e1 border=1>

class Test { public static void test(int i) { String s = i; } }

　　會收到如下錯誤消息：

Test.java:3: incompatible types found : int required: java.lang.String String s = i; ^ 1 error

　　執行以下 Ruby 代碼：

1 + "hello"

　　會收到以下錯誤消息：

TypeError: String can't be coerced into Fixnum from (irb):3:in '+' from (irb):3

　　這兩種語言都傾向于強類型，因為當您試圖使用一個它們期望之外的類型結構的對象時，它們都會拋出錯誤消息。Java 類型策略在編譯時給出錯誤消息，因為它執行靜態類型檢查。而 Ruby 則是在運行時給出錯誤消息，因為 Ruby 支持動態類型。換句話說，Java 在編譯時將對象綁定到類型。而 Ruby 則是在運行時每當更改對象的時候將對象綁定到類型。由于我是在 Java 代碼中，而不是在 Ruby 中聲明變量的，因此可以看到 Java 語言的顯式類型與 Ruby 的隱式類型的工作方式不同。

　　在這三個角度中，靜態類型與動態類型對于語言的特征有最大的影響，因此接下來我將重點解釋這兩種策略各自的優點。

　　靜態類型的優點

　　在靜態類型語言中，程序員（通過聲明或根據約定）或編譯器（根據結構和語法線索）將一種類型指定給一個變量，然后那個類型就不會改變。靜態類型通常需要額外的成本，因為靜態類型語言（例如 Java 語言）通常是顯式類型的。這意味著必須聲明所有的變量，然后編譯代碼。成本也伴隨著收益：早期的錯誤檢測。靜態類型在最基層為編譯器提供多得多的信息。更多信息所帶來的好處就是，可以更早地捕捉到某些類型的錯誤，而動態類型語言只有到運行時才能檢測到這些錯誤。如果您一直等到運行時才捕捉這些 bug，那么其中一些將進入生產環境。也許這正是動態類型語言受到最多指責的一個方面。

　　另一種觀點則認為現代軟件開發團隊通常會運行自動測試，動態語言的支持者聲稱，即使是最簡單的自動測試也可以捕捉到大多數的類型錯誤。而動態語言的支持者所能提供的對編譯時錯誤檢測不利的最好論據是，早期檢測所帶來的好處相對于成本來說是得不償失的，因為不管是否使用動態類型，最終都要進行測試。

　　一種有趣的折中方法是在靜態類型語言中使用隱式類型，從而減少類型的成本。開放源代碼語言 Objective Caml (OCaml) 是靜態類型語言 Lisp 的衍生物，它既能提供很好的性能，又不會犧牲生產率。OCaml 使用隱式類型，因此可以編寫下面這樣的采用靜態類型的代碼：
　　　　　　　　　　　　　　

# let x = 4+7 OCaml 返回： val x : int = 11

　　根據表達式中的語法線索，OCaml 推斷出 x 的類型。4 是 int 型，7 也是 int 型，因此 x 也必定是 int 型。隱式類型語言可以擁有 Java 語言所具有的所有類型安全性，甚至更多。不同之處在于您需要提供的信息量，以及在閱讀程序時可用的信息量。很多喜歡靜態類型的人更偏愛隱式類型。他們寧愿讓編譯器來做這種事情，而不愿意被迫重復地在代碼中輸入變量的類型。

　　隱式類型系統一個較大的優點是，不需要為函數的參數聲明類型，因為編譯器會從傳入的值推斷出參數的類型。因此同一個方法可以有多種用途。

原文轉自：http://www.kjueaiud.com