談 kotlin之前

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

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

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

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

簡潔的語法

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

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

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

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

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

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

//快速創(chuàng)建一個Bean類 
data class Person(val id: Long, var name: String, var age: Int) 
 
fun main() { 
    // 創(chuàng)建實例 
    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) 
} 

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

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

空指針

Java 的空指針異常被稱之為 “Billion Dollar Mistake”。在上家公司的時候為了避免空指針異常，代碼規(guī)范要求幾乎所有的對象都要進行判空操作，那種嵌套很深的json對象，判空起來真的是又臭又長。

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

上面的代碼解釋了三種對可能為空的對象的處理。其實我把 Kotlin 對空指針的處理歸類為給所有對象加了個范型——符號?，對于帶?的對象則表明它可能為空，你不處理直接使用的話不讓編譯，也就是把空指針盡量扼殺在編譯期間。這個想法真的是簡單又巧妙。很多人一聽 Kotlin 就說沒有空指針了，但是沒用過的話并不知道怎么實現(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)用該方法的時候更加靈活 
        action() 
    } 
    toolbar.setNavigationOnClickListener { 
        Log.d("AppCompatActivity", "finish") 
        finish() 
    } 
} 
 
//------------------------分割線----------------------------- 
//類似的單方法接口現(xiàn)在只需要寫一個閉包就行了 
binding.aliPayIcon.setOnClickListener { 
    Log.d("example", it.contentDescription.toString()) 
} 
 
//擴展函數(shù)let，只有在對象不為空的時候會調(diào)用，相當(dāng)于做了判空 
binding.let { 
    it.setLifecycleOwner(this@WithdrawActivity) 
    it.viewModel = vm 
} 
 
//擴展函數(shù)apply, 在閉包內(nèi)可直接調(diào)用對象的方法屬性，有個好處就是可以直接操作對象不需要先生成變量 
vm.accountName.apply { 
    this.value = "aaaa" 
    Log.d("example", this.value?.toString() + ":" + this.hashCode()) 
} 
 
//還有其他基礎(chǔ)擴展函數(shù)run, with, also等等，可以看看這篇博客的介紹：https://www. 

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

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

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

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

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

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

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

結(jié)語

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

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

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