遇见Kotlin

消失的Getter和Setter

Java写的贼溜：

class Student{
    private String name;
    private int age;

    //以下省略Get和Set方法

老铁，这没毛病！！ 你喜欢Java语言，原因也很朴实，因为其他的也不怎么会啊。

直到有一天，你要写个视频的app。 时长，大小，收费不···有用没有的字段20来个，写个Get,Set一眼都望不到边。这个时候你也曾尝试着去掉Get，Set, 但作为一个从“大象进冰箱”过来的人，没有了Get Set让你感觉像是：

后来，你发现Kotlin可以这样来：

data class Student(val name:String, var age:Int)

使用的时候是这个样子：

val student = Student("li", 13)
println(student)

其实除了Get,Set外，Kotlin还帮你实现好了toString(),hashCode(),equals(),copy().
哎呦，不错哦！你眼前一亮，有了继续看下去的想法。

无奈的 ButterKnife

“真的要再见了吗，你忘了我们曾经的默契吗？”
“不，你永远是最好的。”
“可是你明明就是喜欢上了Kotlin-Android-extensions。” Butterknife有些不耐烦了。
你心头微微一颤，是的，你掩盖不了你的内心，你有了新欢。

过去你的View都是用ButterKnife注入的：

@BindView(R.id.nameView) TextView nameView;
...
nameView.setText("橘右京");
...

现在呢,在也不需要写什么findViewById()了。

nameView.setText("橘右京")

烦人的空指针

上班什么时候最刺激，当然是去看司南报错的时候了。在长长的一排Crash中，肯定有很多NullPointException的影子，空指针本身并没有什么问题，你曾经甚至看着鲜红的报错日志信誓旦旦，这样的错误我一分钟能改俩。但是渐渐的你发现不对，为什么他总萦绕耳畔？为什么Java允许潜在的空指针？你思索着，一定是什么蒙蔽了你的双眼，让你看不透寻不见。

蓦然，你看到自己电脑上的一行代码：

student.setName("橘右京");

这童鞋叫 橘右京，可这童鞋是谁？万一他是一个 null 呢？

你目光上移，看到了那行赋值语句：

Student student = findStudentFromCache();
student.setName("橘右京");

findStudentFromCache()方法是谁写的，在什么情况下会返回null吗？

你心里开始有点慌了，我们的java代码处处不让我们放心啊！

你还记得if(x != null) x.y()吗? 还记得写下这种代码时的迷之担忧吗？(敏娜姐曾经批评过这样的写法，认为只要逻辑梳理的清晰就不会存在这样的情况)

除了你保证findStudentFromCache()不会返回null外，还有更好的办法吗？

来个应景的，我们的报错统计：

或许Kotlin有更好的办法：

fun findStudentFromCache():Student{
    return ...
}

当你试图返回一个null时，聪明的Studio在你的代码下画一条红线，告诉你不能这样。你似乎感觉到有了一丝安心。
你查下资料，发现:Student在Kotlinz中表示返回一个不可为null的Student对象，这次再面对如下代码，就感觉无比的踏实了。因为编写findStudentFromCache方法的家伙必须要小心翼翼保证可以送你个“对象”，不然编译器是不会放过他的。

Student student = findStudentFromCache();
student.setName("橘右京");

代码虽好，可……万一我真的没对象呢？

你继续在kotlin中寻找帮助。

fun findStudentFromCache():Student?{
    return ...
}

注意到区别了吗？ :Student?,就表示该方法可以返回一个null。这时候你会注意到：

val student = findStudentFromCache();
student.setName("橘右京");

第二行报错了：

Only safe (?.) or non-null asserted (!!.) calls are allowed on a nullable receiver of type String?

也就是说这不是一个负责人的家伙可能给我返回一个null,我在使用之前要做判断了。

难道又要写if判断那种有伤风化的代码了？开玩笑，Kotlin可是处理假对象(null)的专业户。

如果为null直接返回你可以这样写：

val student = findStudentFromCache()?:return

如果你也任性，为null 就是不处理,可以这样写：

student!!.setName(“橘右京”)

当然很多时候我们要温柔的多(毕竟bug多了，要被叫去谈话的)

student?.setName(“橘右京”)

此时你的内心：

打日志

日志是谁？你们为什么要打日志？麻烦叫上我好不好？[嘿嘿嘿]

桌面VerticalViewPager类第 1895行代码：

丑不丑？(或许你已经习惯他的丑了！)
那Kotlin会不会带来什么惊喜呢？

再见，Utils

还记的String怎么判断不为空吗？

str.noEmpty()

看着红红的报错，你了然：String没有noEmpyt()方法啊！

!("".equals(str))

这真是不雅观啦，一堆的括号！一怒之下写了一个工具类：

public class StringUtils{
    public static boolean notEmpty(String str){
        return !"".equals(str);
    }
    public static boolean isEmpty(String str){
        return "".equals(str);
    }
}

嗯，这下好多了。你点只烟看看窗外，这下应该没什么问题了。

但是只到有天，你发现你旁边的同事也在写着相同的代码！！
Util是很反设计的存在啊，判断String自己为不为空，却还要拉上其他人。
这不好，你有些惆怅，我要是能重写String类就好了，一定给加上这俩方法。

这时你的眼前浮现出这样的代码：

fun String.noEmpty():Boolean{
    return "" != this
}

fun String.isEmpty():Boolean{
    return this == ""
}

通过方法扩展，之后我们就可以直接调用扩展的方法

val str = "message"
str.onEmpty()

你简直不敢相信，Kotlin大法就是好！！

逆袭的函数

高阶函数，名字吓的你一激灵。一番交流才知道，原来高阶函数是指可以接受函数作为参数或者以函数作为返回值的函数。

嗦嘎，函数在kotlin中晋升为一等公民了，可以在函数之间进行传递。

似懂非懂的你写下如下代码：

fun SharedPreferences.editor(f:(SharedPreferences.Editor) -> Unit){
    val editor = edit()
    f(editor)
    editor.apply()
}

//调用
PreferenceManager.getDefaultSharedPreferences(null).editor{
   it.putBoolean("is_ok", true)
}

你感觉像接口，但似乎又不同，可以传递函数总归要比不能传递看起来高级一点吧！你摇摇头感叹自己要学习的东西还有很多，但有一点越来越清晰了，你已经在kotlin中浏览忘返了。