kotlin的一些特性介绍和与java C 的简单对比
为何是kotlin:
很多人对kt没有一个正确的定位,可能大家第一反应是拿它去和scala,groovy比较.
从语法的角度而言,kotlin丰富且严谨到恰到好处的语法糖,表达能力强但不啰嗦,极少的代码冗余。
但老实讲能做到这些的语言也不算少，单看语法，事实上kt比scala还是要略差一筹的，
他们都是非常优秀的jvm语言,总体来说是难分伯仲,kt也没办法将他们甩出一个身位.
但我必须得说,绝大部分情况下(指常规开发),如果你选择kt作为你的第二jvm语言,比用scala,groovy等,
开发工程中的收益要多的多的多...成本亦低的多的多的多(注意我不是单单在说语言层面了)
首先，最重要也是让kotlin与其他jvm语言有本质不同的地方在于：无缝和java程序的衔接以及极低的交互成本。
老项目想尝新？在maven或gradle里面加个配置，就能开写kotlin了.
不敢直接用？先用来写UT啊,UT写顺了，你自然会忍不住想继续写。
已有java代码怎么办？直接用啊，封装都不用，两者可以直接调用，智能提示也都在，反过来kotlin写的库java同样能用。
kotlin的一些典型特征:
静态强类型
这个不多说，java，C#，kotlin都是典型，稍微上点规模的项目，都应该用静态强类型来打底子。TypeScript越来越火也可见一般。
当然我不是说静态就优于动态，这是看场景的，比如需求相对复杂和稳定的后端和随业务迅速迭代的前端，他们的技术诉求肯定就不一样。
比如做gateway，我就觉得动态类型的语言更适合，参考阿里的node.js使用场景。
学习成本
其实大家回忆下学习语言的过程,是花在语法上的时间多,还是花在熟悉标准库上的时间多?
而kotlin则完全没有后者的成本,time还是用的joda,http还是Apache的HttpClient,或者OkHTTP，
也会纠结netty，tomcat，akka 的方案选型，同样需要注意集合类的时间复杂度和线程安全情况。
可以说在熟悉java生态的前提下学习kt，成本是非常低的。
其实我给人安利时候，一般给C#的人说Kotlin，就是“jvm届的C#”
给Java的人说：“你别把它当新语言，你就把他当Java9”，当然9现在已经发布了，我可以换成10了，哈哈。
学习新语言总是会给人带来一些压力，但也要注意语言和语言之间的学习成本的不同，
我曾开玩笑说：我学习scala（入门）花的功夫，足够我学会js，php，python这三门语言了。
而kt的低成本高收益，才是我对它如此推崇的最大原因。
生态支持
最后,也是最重要的优势:jetBrains爸爸全方位无死角超贴心的配套支持
(画外音:用过Resharper,IDEA,WebStorm,PyChrome的朋友,让我看到你们的双手!!)
熟悉jetBrain的朋友,应该能够感觉到,这是一家非常有特色和魅力的公司,其在ide和pl工程领域的积累,大家应该也心里有数.
j系ide都有一个特点,就是对开发者极其友好,
基于语法(AST?)而非文本的代码分析,带来的超高的智能提示准确率和极度便利的重构,
对可能的异常代码的警告和解决方案的提示.jetBrains总是倾向于让开发者写出严谨又简洁且鲁棒的代码。
幸运的是,kt也继承了爸爸的这些特质,不仅仅是语法的严谨,还体现在了开发过程中。
比如maven配置,java交互,nullable的注解提示,idea配套插件.
而且kt是他们内部很早就立项的语言，他家的各路ide都是用kt写的。
各种插件个ide的支持，基本可以和语言版本同步迭代。
说了这么多文字,且废话占多数,想必大家也有点烦了,那我下面就以java和kt的比较为切入点,介绍一些kt的特点吧。
其实就是过一遍 Kotlin/kotlin-koans,建议有兴趣的可以clone个玩玩。
val 定义的变量不可变
var 同C#,val和var都是隐式强类型推断,
val的作用在于,我前面定义一个orderState,即表示,这个变量就只做取值用途,你别再拿来干别的事情了,避免了一值多用的bad small.
默认参数,及参数名传参:
减少无意义多态的使用,但又比js的一值多用直观的多.
labmda写法改进
必须在一个花括号中,如果以lambda为参数,可省略(),看起来很舒服
如果只有一个参数,则可以省略声明,用it代替,(同scala的 _ )
scala的一个参数对应的_只能出现一次,第二个_代表第二个参数,更简洁的写法但带来更模糊的语义,孰优孰劣不谈,但两者的风格差异在这个细节中可见一斑.
nullable
kt对null pointer 问题非常敏感,任何可能的npr都需要显示的处理,如果不处理,nullable会一直往后传染并给出一个警告,
这时候你要么用!!表示我tm确定这里肯定不为null,要么用?:表示如果为空,则表达式的值为后面提供的缺省值. 这个设计基本和C#那边的一样
tems是订单详情的集合,详情包含ActualWeight,但未发生实提则为null,如果是传统写法,需要先判断find出来的是否是null,再判断这个find是否有实提,如果有则返回实提,没有则返回double 0(lambda可省略return)
大家可以体会下这省了多少工夫?
扩展方法,
这是我觉得所有静态语言都应该提供的特性,原理非常简单,但带来的写法上的优化非常有价值
kt和C#扩展方法原理大致类似，就是this作为第一个参数传给静态方法的一个语法糖，但kt不要求强制定义在一个静态方法中
表示所有的string实例,在lastChar的可访问范围内,都多了一个成员函数,其实就是
static StringHelper.lastChar(str:String)
的变种,在不支持em的java看来,就长刚才这个样子,用起来就是如下形式:
H3.em3(H2.em2(Helper1.em1(what)))
low爆了是吧? 下面是我封装的一个操作poi的代码
next是移动到下一单元格,设置样式是复制第一行的样式,其实还可以封装,为了显示表达出我的操作意图,这里就留着了.
说到这里就差不多了,再说也就是抄袭koans,也没啥大的意思了,最后扯点其他的作收尾吧.
谈一谈我对语法糖的看法:
我个人对语法糖的评价是非常高的,也许这个糖的原理并不复杂,比如我之前提到的扩展方法,但我们认识它的原理是远远不够的,还得理解,为什么要有这玩意.
H3.em3(H2.em2(Helper1.em1(what))) VS what.em1().em2().em3()
上面后者省略了import H1 H2 H3的过程,综合起来工作量也没差太多
但真的就仅仅是写法和视觉上的优化吗?其实远远不止.
前者是,XXHelper里面有个方法,可以操作what这个类型并做一些事情,
后者是,what既然有这样的特质,那么它就应该拥有某样的能力
前者是思维先找到Helper,再找到具体方法,
后者是what自然而然的提示出,what就有这样的能力(ide的智能提示),我敲下what+ . 后,它的能力就展示在我面前了,而不需要我还去翻箱倒柜的找helper方法.
谈谈激进技术的风险和收益,与不同阶层人员关注点的不同.
我最早推进kt的时候,最大的阻力就是来自公司的架构师团队,他们的关注点是:
kt相比java,能提高性能吗?(不能,kt的性能与java极度接近但略小与java)
kt解决了什么java并不能解决的问题吗?(没有,kt只是让你更快更好的写java代码)
kt能减少项目bug,提高项目稳定性吗?(某种程度上来说有一定帮助,但更多是看人,这理由也不够强力)
那时候我只是个开发 leader,这种层面肯定是没有太大的决策权的,他们的想法我也理解,公司几百号开发,提高一点点效率,相比引入新技术栈的风险,肯定是稳定压倒一切啦.