吐槽kotlin之垃圾设计

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

一.没有static关键字

static其实不是很面向对象,但是是很有必要和方便的。

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

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

kotlin 复制代码
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++)等混合编译、条件编译等复杂情况,建议不要用了

七 .结束

打完收工,今天喷点结束

相关推荐
向宇it10 分钟前
【从零开始入门unity游戏开发之——unity篇01】unity6基础入门开篇——游戏引擎是什么、主流的游戏引擎、为什么选择Unity
开发语言·unity·c#·游戏引擎
是娜个二叉树!27 分钟前
图像处理基础 | 格式转换.rgb转.jpg 灰度图 python
开发语言·python
Schwertlilien30 分钟前
图像处理-Ch5-图像复原与重建
c语言·开发语言·机器学习
liuyunshengsir33 分钟前
Squid代理服务器的安装使用
开发语言·php
只做开心事42 分钟前
C++之红黑树模拟实现
开发语言·c++
很楠不爱1 小时前
项目实战——高并发内存池
开发语言·项目实战
程序员buddha2 小时前
C语言从入门到放弃教程
c语言·开发语言
程序员老冯头2 小时前
第十五章 C++ 数组
开发语言·c++·算法
南七澄江2 小时前
各种网站(学习资源及其他)
开发语言·网络·python·深度学习·学习·机器学习·ai
van叶~2 小时前
探索未来编程:仓颉语言的优雅设计与无限可能
android·java·数据库·仓颉