在深入到函数式编程思想之前,了解函数式独有的类型是非常有必要的。函数式类型跟OO语言中的数据结构截然不同,这也导致使用函数式编程语言来解决问题的思路跟OO的思路有明显的区别。
什么是类型?类型在编程语言中有什么作用呢?一般来说,类型有两个作用:
首先当你对某个数据声明类型后,就拥有了编译时的检查,换句话说,你可以认为类型充当了“编译时的单元测试”;
类型系统可以让你建立一种模型,用来表达真实世界中的模型;
Tuple type元组是函数式编程语言中的常用类型,同时在.NET 4.0中被引入到了C#中。但是在C#中几乎不太会用到这种类型,但是在函数式编程语言中却随处可见。
例如在C#中这样使用元组:
在F#中
let t = 1,2 let first = fst t //提取第一个元素 let second =snd t //提取第二个元素 let f s = t //通过解构提取元素 Record typeRecord type是F#中最常用的类型。经常被用来对领域建模(Domain modeling)。例如定义一个矩形数据结构:
type Rect = { Left: float32 Top: float32 Width: float32 Height: float32 }这看起来跟OO语言中对class的定义是很相似的,好比在某个class中声明了一组属性。使用起来也简单:
let rc = { Left = 10.0f; Top = 10.0f; Width = 200.0f; Height = 200.0f }你可以把它当做一个简单的class,但是从定义和使用都能看出来Record type更加简单和直接一些。并且我们并没有在Record type里设计一些方法,这根class有本质的区别。
Record type还支持“复制一个现有记录并进行一些修改”:
C#中的class是没有这种能力的,你不得不显示复制所有属性。
另外Record type自动实现了equal操作符:
考虑下面的Contact领域模型:
type Contact = { FirstName: string; MiddleName: string; LastName: string; EmailAddress: string; Address1: string; Address2: string; City: string; State: string; Zip: string; }如果你把它当做一个class也是可行的,实际上在OO语言里我们也经常设计这样的class。这样的模型定义犯了三个错误:
没有把相关一组类型组合起来,例如FirstName, MiddleName, LastName。这三个类型共同组成了Name,我们的模型并没有体现出这样的设计。
EmailAddress真的是一个string吗?他能有效的表达Email这样的Domain吗?Email分有效和无效,他拥有自己的规则,并不是所有的字符串都是Email,string这样的类型无法表达Email的Domain含义。
在F#中没有null,如果你认为某个类型可能为空,就应该设计为option类型,例如MiddleName,他应该是string option。
还记得前面的章节我们说函数式编程的核心思想是组合,组合不但体现在函数之间的组合,类型也是可组合的:
中文翻译过来叫做可区分联合,这种类型试图来为不同的选项进行建模,所以你可以把他理解为选项类型。
举个例子:“现在温度是多少?“
如何对现在的温度建模?你问的是摄氏度呢还是华氏度呢?如果是摄氏度即38°,如果单位是华氏度,则为100.4°。
只有一个选项的类型:
type EmailAddress = EmailAddress of string let email = "a" |> EmailAddress let emails = ["a"; "b"; "c"] |> List.map EmailAddress 使用 Descriminated Unions type来建立领域模型选项类型在F#是非常常用的领域模型建模类型,比如设计一个关于支付的模型,在OO语言中,你可能会这样做:
interface IPaymentMethod { } class Cash : IPaymentMethod { } class Cheque: IPaymentMethod { } class Card : IPaymentMethod { } ...在函数式语言中利用选项类型可以轻松搞定:
type PaymentMethod = | Cash | Cheque of ChequeNumber | Card of CardType * CardNumberOO思想中通过抽象接口和定义派生类来实现这个模型。函数式语言则利用选项类型把模型核心内容通过尽可能少的代码展现出来。
此时你也许会有所疑虑,在OO的设计中,每种支付方式都是一个独立的实现,所以每种支付方式的具体行为就可以设计在具体的实现中,例如Payment的过程。不同的支付方式显然需要不同的支付过程,这种设计在OO中的好处是显而易见的。
在选项类型中,似乎把三种不同的支付方式揉在了一块,那么每种支付方式的支付过程这种行为怎么实现呢?答案是模式匹配,我们将在下节介绍。