當(dāng)談到 Java 語(yǔ)言的類型方法時(shí)，Java 社區(qū)分為兩大陣營(yíng)。一些人喜歡編譯時(shí)錯(cuò)誤檢查，更好的安全性，以及改善的工具 ?? 這些都是靜態(tài)類型所能提供的特性。而另一些人則偏愛(ài)更動(dòng)態(tài)的類型體驗(yàn)。這一次在 跨越邊界 中，您將看到兩種高生產(chǎn)力的非 Java 語(yǔ)言所使用的一些截然不同的類型策略，并發(fā)現(xiàn)在 Java 編程中提高類型靈活性的一些方法。

　　在對(duì)任何編程語(yǔ)言的討論中，爭(zhēng)議較大的一個(gè)問(wèn)題就是類型模型。類型決定可以使用哪些種類的工具，并影響到應(yīng)用程序的設(shè)計(jì)。很多開發(fā)人員將類型與生產(chǎn)率或可維護(hù)性聯(lián)系起來(lái)（我就是其中的一個(gè)）。典型的 Java 開發(fā)人員通常都特別樂(lè)于維護(hù) Java 語(yǔ)言的類型模型的地位，強(qiáng)調(diào) Java 語(yǔ)言可采用更好的開發(fā)工具，在編譯時(shí)捕捉某些種類的 bug（例如類型不兼容和拼寫錯(cuò)誤），以及性能等方面的優(yōu)勢(shì)。

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

　　類型策略

　　至少可以從三個(gè)角度來(lái)看待類型：

　　靜態(tài)類型還是動(dòng)態(tài)類型，這取決于何時(shí) 實(shí)施類型模型。靜態(tài)類型語(yǔ)言在編譯時(shí)實(shí)施類型。而動(dòng)態(tài)類型語(yǔ)言通�；�于一個(gè)對(duì)象的特征在運(yùn)行時(shí)實(shí)施類型。

　　強(qiáng)類型還是弱類型，這取決于如何 實(shí)施類型模型。強(qiáng)類型嚴(yán)格地實(shí)施類型，如果發(fā)現(xiàn)有違反類型規(guī)則的情況，則會(huì)拋出運(yùn)行時(shí)或編譯時(shí)錯(cuò)誤。而弱類型則留有更多的余地。極端情況下，弱類型語(yǔ)言（例如 Assembler）允許將任意數(shù)據(jù)類型賦給另一種類型（不管這種賦值是否有意義）。靜態(tài)類型的語(yǔ)言既可以有強(qiáng)類型，也可以有弱類型；而動(dòng)態(tài)類型系統(tǒng)通常是強(qiáng)類型的，但也不完全是。

　　顯式類型還是隱式類型，這取決于語(yǔ)言如何確定一個(gè)給定對(duì)象的類型。顯式類型語(yǔ)言要求聲明每個(gè)變量和每個(gè)函數(shù)參數(shù)。而隱式類型語(yǔ)言則根據(jù)語(yǔ)言中的語(yǔ)法和結(jié)構(gòu)線索來(lái)確定對(duì)象的類型。靜態(tài)類型語(yǔ)言通常是顯式類型的，但也不完全是；而動(dòng)態(tài)類型語(yǔ)言幾乎都是隱式類型的。

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

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

　　會(huì)收到如下錯(cuò)誤消息：

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

　　執(zhí)行以下 Ruby 代碼：

1 + "hello"

　　會(huì)收到以下錯(cuò)誤消息：

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

　　這兩種語(yǔ)言都傾向于強(qiáng)類型，因?yàn)楫?dāng)您試圖使用一個(gè)它們期望之外的類型結(jié)構(gòu)的對(duì)象時(shí)，它們都會(huì)拋出錯(cuò)誤消息。Java 類型策略在編譯時(shí)給出錯(cuò)誤消息，因?yàn)樗鼒?zhí)行靜態(tài)類型檢查。而 Ruby 則是在運(yùn)行時(shí)給出錯(cuò)誤消息，因?yàn)?Ruby 支持動(dòng)態(tài)類型。換句話說(shuō)，Java 在編譯時(shí)將對(duì)象綁定到類型。而 Ruby 則是在運(yùn)行時(shí)每當(dāng)更改對(duì)象的時(shí)候?qū)��?duì)象綁定到類型。由于我是在 Java 代碼中，而不是在 Ruby 中聲明變量的，因此可以看到 Java 語(yǔ)言的顯式類型與 Ruby 的隱式類型的工作方式不同。

　　在這三個(gè)角度中，靜態(tài)類型與動(dòng)態(tài)類型對(duì)于語(yǔ)言的特征有最大的影響，因此接下來(lái)我將重點(diǎn)解釋這兩種策略各自的優(yōu)點(diǎn)。

　　靜態(tài)類型的優(yōu)點(diǎn)

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

　　另一種觀點(diǎn)則認(rèn)為現(xiàn)代軟件開發(fā)團(tuán)隊(duì)通常會(huì)運(yùn)行自動(dòng)測(cè)試，動(dòng)態(tài)語(yǔ)言的支持者聲稱，即使是最簡(jiǎn)單的自動(dòng)測(cè)試也可以捕捉到大多數(shù)的類型錯(cuò)誤。而動(dòng)態(tài)語(yǔ)言的支持者所能提供的對(duì)編譯時(shí)錯(cuò)誤檢測(cè)不利的最好論據(jù)是，早期檢測(cè)所帶來(lái)的好處相對(duì)于成本來(lái)說(shuō)是得不償失的，因?yàn)椴还苁欠袷褂脛?dòng)態(tài)類型，最終都要進(jìn)行測(cè)試。

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

OCaml 返回：

val x : int = 11

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

　　隱式類型系統(tǒng)一個(gè)較大的優(yōu)點(diǎn)是，不需要為函數(shù)的參數(shù)聲明類型，因?yàn)榫幾g器會(huì)從傳入的值推斷出參數(shù)的類型。因此同一個(gè)方法可以有多種用途。

標(biāo)簽： isp 安全 代碼 問(wèn)題

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。