談 kotlin之前

有一類程序員，自己根本沒體驗(yàn)過的東西，看了幾篇嘩眾取寵的博文自己也來嘲諷，我稱之為云程序員。

就比如 Kotlin，有人蹭熱度寫幾篇類似“我為什么從 kotlin 又回到j(luò)ava”的博文，就把 kotlin 一通批判。有空看看這些蹭熱度博文為啥不看看Android Developer 官網(wǎng)所有示例代碼都是 kotlin 版本在前，java 版本在后呢?

爭(zhēng)論語言、框架的優(yōu)劣是沒有意義的。很多程序員總是對(duì)自己一直使用的語言、框架大肆吹捧而對(duì)其他語言、框架各種貶低，很明顯這樣的程序員太狹隘了。

Java確實(shí)常年***，其他語言就沒有意義了嗎?當(dāng)然不是，即使是批判，你也得自己真的體驗(yàn)過了才有資格。這可不是你行你上的翻版，畢竟了解一門新語言對(duì)一個(gè)真正程序員老說是很輕松的事。

簡(jiǎn)潔的語法

Kotlin給我的感覺就是它就是針對(duì)Java里所有的痛點(diǎn)來做改變的，比如語法繁瑣，煩人的空指針，缺少函數(shù)式編程支持(Java8雖然支持Lambda表達(dá)式但還遠(yuǎn)遠(yuǎn)不夠)等等。

不像它的孿生兄弟Scala那樣奔放，Kotlin給我的感受是聰明又克制，對(duì)Java程序員來說半天就足夠上手開干了，不像Scala門檻那么高。

Java語言是我所接觸過語言中語法最繁瑣的(有更繁瑣的請(qǐng)告知)，這種繁瑣在main函數(shù)就可以體現(xiàn)，而且Java可能也是唯一一個(gè)幾乎沒法不用IDE的語言。其他語言脫離了IDE的語法警告和代碼生成模版也勉強(qiáng)能寫一寫，Java代碼你沒有試試看?

但是Java的語法之嚴(yán)謹(jǐn)和繁瑣恰恰是Java如此流行的原因。沒寫過Java的人可能沒法理解這句話。人們對(duì)于Java嚴(yán)苛的語法還不夠滿意，還要再加上 check-style，findbugs以及各種XXX公司Java代碼規(guī)范等各種條條框框，最終得到的結(jié)果是所有Java程序員寫出來的代碼都能互相看懂。

即使是剛畢業(yè)不久的Java程序員，只要熟悉Java面向?qū)ο笳Z法，幾乎不存在看不懂其他Java代碼的情況(業(yè)務(wù)看不懂除外)。這樣保證了Java程序員的代碼下限非常之高，能夠保證大型項(xiàng)目的成功。

好像扯 Java 扯的有點(diǎn)多了。接觸 Kotlin 之后會(huì)發(fā)現(xiàn)，kotlin 在盡可能保持和 Java一樣的語法嚴(yán)苛性的情況下，大幅度地精簡(jiǎn)了 Java 代碼，寫起來非常之爽。

//快速創(chuàng)建一個(gè)Bean類 
data class Person(val id: Long, var name: String, var age: Int) 
 
fun main() { 
    // 創(chuàng)建實(shí)例 
    val zhangsan = Person(0L, "zhangsan", 23) 
    // set/get方法 
    zhangsan.age = 24 
    val name = zhangsan.name 
 
    //copy方法 
    val lisi = zhangsan.copy(id = 1, name = "lisi") 
    //默認(rèn)生成的tostring和equals/hashcode方法，可重寫 
    zhangsan.toString() 
    zhangsan.hashCode() 
    var isEqual = zhangsan.equals(lisi) 
} 

簡(jiǎn)潔的語法無處不在，比如上面的Bean類如果用java來寫至少要多好幾倍的代碼。單例模式只需要把class換成object即可。這些雖然用Java的IDE的各種模版生成工具一樣可以秒生成，但是還是kotlin寫起來更舒服一些。

我想強(qiáng)調(diào)的是，Kotlin并不是無腦地利用語法糖和新關(guān)鍵字來精簡(jiǎn)語法，我們可以很清晰地感受到Kotlin在設(shè)計(jì)過程中盡可能地保證它盡可能的語法嚴(yán)苛性。

空指針

Java 的空指針異常被稱之為 “Billion Dollar Mistake”。在上家公司的時(shí)候?yàn)榱吮苊饪罩羔槷惓＃a規(guī)范要求幾乎所有的對(duì)象都要進(jìn)行判空操作，那種嵌套很深的json對(duì)象，判空起來真的是又臭又長(zhǎng)。

val name: String? 
//這里要吐槽下為啥kotlin沒有三目運(yùn)算符？ 
name = if(Random.nextBoolean()) "Ann" else null 
//加上？則只在name不為null的時(shí)候會(huì)調(diào)用，得到的len1類型也是有問號(hào)的，即Int? 
val len1 = name?.length 
//這種寫法是如果為空給一個(gè)默認(rèn)值，得到的len2類型為Int，不帶問號(hào) 
val len2 = name?.length?:0 
//加上雙感嘆號(hào)其實(shí)就是java什么都不加的寫法了，如果為null會(huì)報(bào)空指針異常 
val len3 = name!!.length 

上面的代碼解釋了三種對(duì)可能為空的對(duì)象的處理。其實(shí)我把 Kotlin 對(duì)空指針的處理歸類為給所有對(duì)象加了個(gè)范型——符號(hào)?，對(duì)于帶?的對(duì)象則表明它可能為空，你不處理直接使用的話不讓編譯，也就是把空指針盡量扼殺在編譯期間。這個(gè)想法真的是簡(jiǎn)單又巧妙。很多人一聽 Kotlin 就說沒有空指針了，但是沒用過的話并不知道怎么實(shí)現(xiàn)的。現(xiàn)在再有面試官問你，知道怎么回答了吧?

函數(shù)式編程

fun AppCompatActivity.setupActionBar(@IdRes toolbarId: Int, action: ActionBar.() -> Unit) { 
    val toolbar = findViewById<Toolbar>(toolbarId) 
    setSupportActionBar(toolbar) 
    supportActionBar?.run { 
        //執(zhí)行參數(shù)中的函數(shù)，這樣用戶在調(diào)用該方法的時(shí)候更加靈活 
        action() 
    } 
    toolbar.setNavigationOnClickListener { 
        Log.d("AppCompatActivity", "finish") 
        finish() 
    } 
} 
 
//------------------------分割線----------------------------- 
//類似的單方法接口現(xiàn)在只需要寫一個(gè)閉包就行了 
binding.aliPayIcon.setOnClickListener { 
    Log.d("example", it.contentDescription.toString()) 
} 
 
//擴(kuò)展函數(shù)let，只有在對(duì)象不為空的時(shí)候會(huì)調(diào)用，相當(dāng)于做了判空 
binding.let { 
    it.setLifecycleOwner(this@WithdrawActivity) 
    it.viewModel = vm 
} 
 
//擴(kuò)展函數(shù)apply, 在閉包內(nèi)可直接調(diào)用對(duì)象的方法屬性，有個(gè)好處就是可以直接操作對(duì)象不需要先生成變量 
vm.accountName.apply { 
    this.value = "aaaa" 
    Log.d("example", this.value?.toString() + ":" + this.hashCode()) 
} 
 
//還有其他基礎(chǔ)擴(kuò)展函數(shù)run, with, also等等，可以看看這篇博客的介紹：https://www. 

函數(shù)式編程對(duì)很多Java程序員來說是很陌生的。

盡管我不想黑，但是Java真的強(qiáng)到讓很多Java程序員只會(huì)Java一門語言，并且基本上Java8以上的版本也沒接觸過。而除了Java(Java8以下)我還真不知道哪門語言不支持函數(shù)式編程。

幾乎所有語言都支持函數(shù)式編程，因此會(huì)靈活使用函數(shù)式編程真的挺重要。Java不支持是因?yàn)楹瘮?shù)式編程相對(duì)要難一點(diǎn)，不支持函數(shù)式編程反而讓Java代碼的下限更高。

除了難度大一點(diǎn)，函數(shù)式編程最令人不爽的就是閱讀性差(可能比較依賴寫代碼的人的水平)，我看Java框架源碼基本都很順暢，但是看JavaScript框架簡(jiǎn)直懵逼。

我現(xiàn)在的水平看Kotlin函數(shù)式代碼也費(fèi)勁，但是kotlin畢竟是強(qiáng)類型語言，函數(shù)的參數(shù)和返回值類型固定的話，認(rèn)真讀還是不難讀懂的。

扯遠(yuǎn)了，函數(shù)式編程的好處就是代碼靈活度加倍提高，可以寫出各種秀操作的代碼，顯然這也是一把雙刃劍。不過隨著函數(shù)式編程越來越流行，大家的水平越來越高，寫出來的函數(shù)式代碼勢(shì)必越來越好。

可以說Java程序員學(xué)習(xí)Kotlin唯一的難點(diǎn)就是函數(shù)式編程了，當(dāng)然如果你本身就有函數(shù)式編程經(jīng)驗(yàn)這點(diǎn)也不是事。如果沒有的話就要好好學(xué)習(xí)參悟下函數(shù)式編程了，這是一個(gè)相對(duì)漫長(zhǎng)的過程。在熟練掌握之前，不使用函數(shù)式編程也一樣可以寫 Kotlin。

結(jié)語

總的來說我對(duì) Kotlin 的評(píng)價(jià)總體是正面的。不過有些人的腦回路不正常，我還是想說一下：說 Kotlin 好，有優(yōu)點(diǎn)，馬上又有人驚呼Java要被取代啦!過兩天又有人大喊 Kotlin 怎么怎么不好馬上要涼。

Java的好處和適用范圍相信你也明白。而現(xiàn)在還在大量使用的語言都有它各自的優(yōu)點(diǎn)，這個(gè)我就不嘮了，畢竟水平不夠。我是真惡心某些蹭熱度、發(fā)軟文各自騙的博主和公眾號(hào)。

不要聽信我和谷歌說它好，也不要聽信那些碰瓷博主說它不好，有那時(shí)間坐而論道，為啥不抽出半小時(shí)來體驗(yàn)一下 Kotlin 呢?