語言設計中的鴨子類型風格

    在動態語言的世界里一直流傳著一種叫做鴨子類型的風格，其來自諺語：“如果行鴨子一樣走路，像鴨子一樣呱呱叫，那它就是一只鴨子”。

    從鴨子類型，我們可以聯想到它的推導，并不在乎類型的真正實體，只要他的行為有鴨子的特性，那么我們就可以把它當做一只鴨子來看到。在動態語言設計中，可以解釋為無論一個對象是什么類型的，只要它具有某類型的行為（方法），則它就是這一類型的實例，而不在于它是否顯示的實現或者繼承。

    鴨子類型在動態語言中被廣為奉行。某類接口需要一個log接口，換句話說這借口中需要調用傳入對象的log，方法，在動態語言中無論你傳入的是什么對象，只有具有log方法則就是合法的。而java，c#這類靜態強類型語言（當前首先聲明c#已經不是純的靜態強類型語言，它具有dynamic，表達式，當然這里所說的c#是去掉這類特性，或者說C#2.0吧）我們傳入的對象是必須顯示實現該接口的類實例，他們直接必須具有顯示的繼承鏈。

    以上所說的是兩類語言設計中的對抽象的制約的區別。

   Javascript中鴨子型的實現：

function log(logger){

logger.log(“hello world”)；

}

log({log:function(msg){

console.log(msg);

}});

代碼量很少，這里只是一種簡單的約定，而不是強制，使得我們的自控感增強，所以我喜歡javascript這門語言給我的自由度。但是相對于java這類靜態強類型語言而言是將語法的檢查推向了運行時期，延遲了發現問題的時間，不助于我們的調試。在強類型系統的語言中由于具有完備的類型信息，我們可以提高良好的IDE于開發時限制，有助于我們的大規模開發。所以這里沒有對錯，只是看你的選擇和喜愛。如果你是一個優秀的程序員，動態語言這種檢查的推遲對你并無什么問題，因為你能夠有條理次序的節奏型開發。

    關于鴨子型風格這里還得必須提到go語言，也是go語言帶來我對這種風格的思考。

type Logger interface{

   Log(string)

}

我們還可以顯示的定義在消費者方法中，形如;

func SomeFunction(logger interface{Log(string)}){

   logger.Log(“hello world, I am go lang”).

}

實現提供者：

type S struct { }

func (this *S)Log(msg string) {

   console.log(msg)

}

在類型S就是一個實現了Logger的實例。

Go還有一種叫做空接口，能夠容納萬物的東西;

func log(any interface{}) int {

   return any.(I).Get()

}

Go語言不同于其他鴨子類型語言的是它實現了在編譯時期檢查，同時也不失這種自由度。

   另外TypeScript想必你也知道 ，這與google的dart一樣致力于將javascript帶入大規模開發的語言，不同的是TypeScript是javascript的超集，并不是重造一門新語言。他為javascript引入的接口，類型，泛型等較完備的類型系統，是的能夠有更好的IDE支持，從某種程度上來說，這是對鴨子類型或者javascript編譯器的檢查推遲的彌補。