语言设计中的鸭子类型风格

在动态语言的世界里一直流传着一种叫做鸭子类型的风格，其来自谚语：“如果行鸭子一样走路，像鸭子一样呱呱叫，那它就是一只鸭子”。

 

从鸭子类型，我们可以联想到它的推导，并不在乎类型的真正实体，只要他的行为有鸭子的特性，那么我们就可以把它当做一只鸭子来看到。在动态语言设计中，可以解释为无论一个对象是什么类型的，只要它具有某类型的行为（方法），则它就是这一类型的实例，而不在于它是否显示的实现或者继承。

 

鸭子类型在动态语言中被广为奉行。某类接口需要一个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语言带来我对这种风格的思考。

我们还可以显示的定义在消费者方法中，形如 

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编译器的检查推迟的弥补。