Kotlin語(yǔ)言是大名鼎鼎的JetBrains公司（就是可以甩Eclipse數(shù)條大街的IntelliJ IDEA背后的公司）出品的現(xiàn)代的編程語(yǔ)言，之前已經(jīng)在IDEA中蹦達(dá)出來(lái)很多次了；只是最近隨著Google在其2017年的I/O大會(huì)上將其列為Android平臺(tái)官方支持的語(yǔ)言而竄上了熱點(diǎn)。
本文嘗試從函數(shù)式編程的角度管窺Kotlin的特性。
JVM上的函數(shù)式語(yǔ)言生態(tài)
作為一門(mén)比較年輕的編程語(yǔ)言，要想在既有的數(shù)百種語(yǔ)言中脫穎而出，成功吸引開(kāi)發(fā)者的心，對(duì)新的函數(shù)式編程范式的支持是必然不可少的 - 這一點(diǎn)基本成為語(yǔ)言出品商心照不宣的潛規(guī)則了，當(dāng)然在21實(shí)際，不支持面向?qū)ο蟮姆妒揭彩钦f(shuō)不過(guò)去的。
作為基于JVM平臺(tái)的語(yǔ)言，和Java的互操作性肯定是一個(gè)重要的優(yōu)勢(shì)，當(dāng)然這方面已經(jīng)有成熟的函數(shù)式語(yǔ)言scala和更早一點(diǎn)的clojure在前?？赡鼙容^遺憾的是，正統(tǒng)的函數(shù)式編程風(fēng)格太難被傳統(tǒng)的OO程序員所接受，因此基于傳統(tǒng)Lisp的clojure一直曲高和寡，scala在近年來(lái)有變得更加流行的趨勢(shì)，只是目前看來(lái)仍然沒(méi)有跨越期望的引爆點(diǎn)。
有豐富的特性還希望有速度
傳統(tǒng)印象中的靜態(tài)函數(shù)式語(yǔ)言的編譯速度往往會(huì)比較慢，這一點(diǎn)在工程實(shí)踐上是個(gè)很重要的因素。
Kotlin作為后來(lái)者，其開(kāi)發(fā)者認(rèn)為靜態(tài)語(yǔ)言的編譯速度是個(gè)至關(guān)重要的，然后Scala的編譯速度遠(yuǎn)不能令人滿(mǎn)意。對(duì)大型的項(xiàng)目而言，笨拙的編譯速度浪費(fèi)的可是大量的時(shí)間和金錢(qián)；畢竟天下武功唯快不破，更快的編譯時(shí)間意味著更快的反饋周期，更多次的迭代開(kāi)發(fā)。Kotlin的目標(biāo)之一是期望編譯速度可以像Java一樣快，benchmark分析也表明了二者的速度是差別不大的。
基本特性
函數(shù)式語(yǔ)言的基本元素就是function，這一點(diǎn)kotlin倒是沒(méi)有玩太多花頭。用fun關(guān)鍵字來(lái)聲明函數(shù)，函數(shù)是第一等公民，可以支持函數(shù)作為參數(shù)，返回函數(shù)等基本特性。
不可變類(lèi)型支持
Kotlin強(qiáng)制要求程序員聲明某個(gè)特定的變量是否是可變類(lèi)型。
如果是可變類(lèi)型，則需要用var來(lái)聲明；那么后續(xù)程序中任何地方訪(fǎng)問(wèn)變量都會(huì)被IDE給highlight出來(lái)，提醒可能的副作用。因?yàn)榭勺冾?lèi)型意味著內(nèi)部存儲(chǔ)著狀態(tài)，從函數(shù)式編程的角度來(lái)看，狀態(tài)會(huì)影響函數(shù)的純度，帶來(lái)副作用和復(fù)雜性。
函數(shù)聲明
基本的函數(shù)聲明是這樣的
fun thisIsAFunction(x: Int) : Int {
}
當(dāng)然這里的類(lèi)型后置語(yǔ)法和傳統(tǒng)的C家族語(yǔ)言有些不同，但是適應(yīng)起來(lái)倒也不是難事兒。
類(lèi)型推導(dǎo)
Kotlin也支持強(qiáng)大的類(lèi)型推導(dǎo)，從而在很多情況下，可以省略不必言的類(lèi)型指定，簡(jiǎn)化代碼；譬如函數(shù)的返回類(lèi)型可以被自動(dòng)推斷的時(shí)候，其類(lèi)型聲明可以被省略。
特殊的返回類(lèi)型 Unit
Unit是一個(gè)特殊的類(lèi)型，用于指定某個(gè)函數(shù)返回的值可以被省略，類(lèi)似于Java8的Void類(lèi)型。如果一個(gè)函數(shù)沒(méi)有返回值，那么可以指定其返回Unit或者直接省略其返回
fun someFunc(arg: SomeType) : Unit {
// do something with arg
// no return needed
}
// same as above
fun someFunc(arg: SomeType) {
// do something
}
中綴表達(dá)式
中綴表達(dá)式寫(xiě)法更替進(jìn)人的思維習(xí)慣，在定義某些操作符的時(shí)候是非常有用的。此用法往往用于擴(kuò)展已有類(lèi)型的操作，定義的時(shí)候需要滿(mǎn)足以下條件
- 屬于某個(gè)類(lèi)的成員函數(shù)，或者是定義某個(gè)類(lèi)的擴(kuò)展函數(shù)(后邊再回頭來(lái)看)，因?yàn)檫@里我們必須知道左側(cè)的操作對(duì)象是誰(shuí)
- 必須只有一個(gè)函數(shù)參數(shù)（操作符后邊的對(duì)象）
- 用
infix關(guān)鍵字來(lái)標(biāo)記
譬如
infix fun Int.shl(x : Int) -> Int {
/// implementation of shl operation
}
// call site
1 shl 2
命名參數(shù)和默認(rèn)值
這點(diǎn)和Python很像在多個(gè)參數(shù)的復(fù)雜函數(shù)的使用上有很大幫助，能極大提高可讀性減少維護(hù)成本。調(diào)用方可以在調(diào)用點(diǎn)指定需要傳入的參數(shù)的名字；也可以省略掉不需要指定的參數(shù)。
譬如有如下的reformat函數(shù)用于格式化
reformat(str,
normalizeCase = true,
upperCaseFirstLetter = true,
divideByCamelHumps = false,
wordSeparator = '_'
)
調(diào)用點(diǎn)可以簡(jiǎn)單寫(xiě)作
reformat(str, wordSeparator = '_')
// equals to
reformat(str, true, true, false, '_')
這個(gè)功能在傳統(tǒng)的C++/Java里邊沒(méi)有提供，但是IDEA提供了只能提示可以彌補(bǔ)Java的不足；而Kotlin則將其內(nèi)置在語(yǔ)言中了；本身沒(méi)多少?gòu)?fù)雜性在里邊。
高階函數(shù)和語(yǔ)法糖
高階函數(shù)
函數(shù)的參數(shù)可以是一個(gè)函數(shù)，這個(gè)在Kotlin的庫(kù)里已經(jīng)有大量的例子，譬如基本的Sequence的filter函數(shù)攜帶一個(gè)謂詞函數(shù)，其針對(duì)給定的參數(shù)返回一個(gè)Boolean
public fun <T> Sequence<T>.filter(predicate: (T) -> Boolean): Sequence<T> {
return FilteringSequence(this, true, predicate)
}
單參數(shù)函數(shù)的表達(dá)式形式
當(dāng)函數(shù)只有一行實(shí)現(xiàn)的時(shí)候，可以省略其函數(shù)體，直接用=來(lái)書(shū)寫(xiě)，就像復(fù)制給一個(gè)變量一樣
fun add2Numbers(x : Int, y: Int): Int = x+y
Lambda和匿名函數(shù)
匿名函數(shù)用大括號(hào)括起來(lái)，上面的例子也可以寫(xiě)作
val add2Numbers2 = {x : Int, y: Int -> x+y}
函數(shù)調(diào)用的形式省略
當(dāng)函數(shù)僅僅有一個(gè)參數(shù)的時(shí)候，其參數(shù)名字默認(rèn)為it保留關(guān)鍵字可以不用顯示指定。
當(dāng)函數(shù)的最后一個(gè)參數(shù)是一個(gè)函數(shù)的時(shí)候，其函數(shù)體可以用{}塊的方式來(lái)書(shū)寫(xiě)，獲得更好的可讀性。
譬如如下的例子用于打印指定數(shù)目個(gè)偶數(shù)
val printEvens = { x: Long ->
IntStream.range(1, 10000000)
.filter { it%2 == 0 }.limit(x)
.forEach { println(it) }
}
一個(gè)具體一點(diǎn)的例子
假設(shè)要實(shí)現(xiàn)如下功能的函數(shù)
- 遍歷某個(gè)目錄樹(shù)
- 找出所有符合條件的文件夾
- 取其文件絕對(duì)路徑
- 歸并為一個(gè)字符串列表返回
可以通過(guò)如下幾個(gè)函數(shù)完成
fun extractAllDomainDoc(dirName: String) {
File(dirName).walkTopDown().filter { isDocDir(it) }
.map { it.absolutePath }.toList()
}
private fun isDocDir(file: File): Boolean {
return file.isDirectory && isDomainDocDir(file)
}
private fun isDomainDocDir(file: File): Boolean {
return file.absolutePath.split(File.separator)[file.absolutePath.split(File.separator).size - 1] == "doc"
}
這里每個(gè)函數(shù)的含義都是比較清楚易懂的。如果利用上述的省略規(guī)則，那么可以更簡(jiǎn)略的寫(xiě)為
fun extractAllDomainDoc(dirName: String) = File(dirName).walkTopDown()
.filter { isDocDir(it) }
.map { it.absolutePath }.toList()
private fun isDocDir(file: File) = file.isDirectory && isDomainDocDir(file)
private fun isDomainDocDir(file: File) = file.absolutePath
.split(File.separator)[file.absolutePath.split(File.separator).size - 1] == "doc"
類(lèi)型擴(kuò)展函數(shù)
Kotlin 支持對(duì)已有的類(lèi)型添加擴(kuò)展，值需要在任何想要的地方添加想要的功能，則原有的類(lèi)型即可像被增強(qiáng)了一樣具有新的功能，該機(jī)制提供了OO之外新的靈活的擴(kuò)展方式。
譬如默認(rèn)的Kotlin的Iterable類(lèi)沒(méi)有提供并發(fā)的foreach操作，可以通過(guò)擴(kuò)展機(jī)制很容易的寫(xiě)出來(lái)一個(gè)使用ExecutorService來(lái)并發(fā)循環(huán)的版本
// parallel for each, see also https://stackoverflow.com/questions/34697828/parallel-operations-on-kotlin-collections
fun <T, R> Iterable<T>.parallelForEach(
numThreads: Int = Runtime.getRuntime().availableProcessors(),
exec: ExecutorService = Executors.newFixedThreadPool(numThreads),
transform: (T) -> R): Unit {
// default size is just an inlined version of kotlin.collections.collectionSizeOrDefault
val defaultSize = if (this is Collection<*>) this.size else 10
val destination = Collections.synchronizedList(ArrayList<R>(defaultSize))
for (item in this) {
exec.submit { destination.add(transform(item)) }
}
exec.shutdown()
exec.awaitTermination(1, TimeUnit.DAYS)
}
這里在函數(shù)體中，this自動(dòng)會(huì)綁定于被擴(kuò)展的對(duì)象。
如果我們想實(shí)現(xiàn)一個(gè)自動(dòng)將一大堆plantuml文件轉(zhuǎn)換為png格式并copy到指定目錄，因?yàn)槟J(rèn)的plantuml的API是單線(xiàn)程的，我們可以基于上述的parallelForEach實(shí)現(xiàn)來(lái)并發(fā)調(diào)度UML的生成過(guò)程，對(duì)應(yīng)的代碼可以寫(xiě)為
markDownFileLists.parallelForEach {
SourceFileReader(File(it)).generatedImages.firstOrNull()?.apply {
copyFileToDirWith(this.pngFile.absolutePath, getCopyTarget)
println("${System.currentTimeMillis()} - Created png for $it")
}
}
