吐槽kotlin之垃圾设计

本文重点在于吐槽垃圾设计，基本直只说缺点。

一.没有static关键字

static其实不是很面向对象，但是是很有必要和方便的。
kotlin为了实现java的static功能，必须使用伴生类，一般情况下没啥问题，但是反编译之后的class多了一个伴生类，这个类一旦被加载，几乎无法卸载，浪费性能和内存。

这个在别的比方无所谓，但是如下场景 ，是真的有点操蛋了

class UserBatchDTO : Serializable {

    /**
     * uidList
     */
    var uidList: List<Long>? = null


    /**
     * 用户状态，0正常，1禁用
     */
    var status: Int? = null

    /**
     * 用户介绍
     */
    var introduce: String? = null

    /**
     * 审核通过者uid
     */
    var approvedUid: Long? = null

    /**
     * 修改时间
     */
    var updateTime: Date? = null

    /**
     * 角色id
     */
    var roleIds: List<Long>? = null

    companion object {
        @JvmStatic
        val name:String = ""
        private const val serialVersionUID = 1L
    }
}

二.无意义的空值校验

下面的代码是右边代码反编译之后的，参数校验、返回校验，之前听说什么游戏循环几十亿导致性能垃圾，这边请求次数多，无意义的判空多了也是浪费性能

三. 设计思路冲突

这一点和第一点相互关联，或者说是第一点的补充
默认class需要加上open才能被继承，但是做为oop语言，设计理应默认可以被继承，如果想不被继承可以加final，而不是默认final

有人说组合由于继承，但是这不是你默认不能继承的理由。这一点和oop思路冲突

四.代码不一定简洁

1.比如在上文的autowire，kotlin代码还多一点

2.如果写spring，一般还要在class或者方法加open，比一个public单词多一些，因为spring有一些代理，final会导致cglib代理代理失败。open有编译插件，这种魔法无疑不是好的解决方案

3.如果是record对象，kotlin生成了一些无意义的方法，代码膨胀

4.允许为空的字段一定要写默认为null，我建议一个?解决

5.其他隐藏的代码膨胀(class文件)

6.综上能看出为什么服务端用kotlin的意愿不是很强，代码没省略，编译还膨胀，客户端还是可以用用，dsl不错

五.Checked Exception

kotlin去掉了Checked Exception，但是实际上这些异常并不能被忽略，当然有的一窝蜂throwable也是不好

六.这个不全是kotlin的锅

gradle.kts，这个只能喷gradle一坨答辩

基本上80%以上用不上gradle，据目前经验，小项目，没有多平台(比如客户端、游戏)、多语言(c、c++)等混合编译、条件编译等复杂情况，建议不要用了

七 .结束

打完收工，今天喷点结束