关于 Java 笨重一说

查看 826|回复 80
chihiro2014   
其实说难听点就是大部分程序员还是脚本小子,有没有规范,有没有团队协作都是不重要的,自己开心就好。还有吹 Go 生态的,Go 社区现在做的事情不就是把 Java 做的事情重新做一遍吗?有啥区别?如果多看点架构设计、软件工程的书,就能明白 Java 这叫高度工程化,绝对算不上笨重和臃肿,难道建摩天大楼的地基和楼体支撑也叫笨重和臃肿吗?
fengjianxinghun   
模块化可以省掉很多没必要的东西
nl101531   
反正一个应用要是 java 写的,我直觉上就会找个其他 c/c++/rust/go 的替代品,除非别无选择
ojh
OP
  
这种算是遗留下来的习惯式规范,不过有了 lombok 也还好了。 自己的项目可以使用充血模型体验不一样的开发乐趣,公司的项目还是按照大家都习惯的方式来,沟通成本小了很多,其实规范多不一定是坏事。
iseki   
@Lancer777 你说的规范、团队协作、工程化有道理,虽然 Java 搞这么多的规范分这么多层看上去很啰嗦,但是可以让能力经验参差不齐的人写的代码都保持一定的统一,利于团队合作和代码维护
zhouzm   
setter & getter 是 Java 没有 property 导致的,就像 Go 一样,写编译器的省事了,程序员就费事了,直接暴露 field 是不合适的。
msg7086   
唉,现在很多人已经丧失了,认真阅读理解别人的文字,以及好好说话这两种能力。
lanlanye   
关于 Java 笨重,过度设计,Getter/Setter 这些,我简单说一些。
Getter/Setter ,有一个原因是向前兼容性。
没有逻辑在里面,不代表永远没有逻辑在里面。
如果你暴露一个 public 的字段,那么你暴露的就是一个数据,而操作这个数据的代码,在第三方。换句话说,你的类对你的数据将失去控制能力,任由第三方来读写。数据和操作数据的代码就割裂开来了。
而 Getter/Setter 则是方法,或者说代码,你对内部的数据有最终操作权,而别人只能调用你提供的方法。如果有朝一日这个数据被改变了,被废弃了,或者业务逻辑被加强了,那么你不需要跑到几十个办公室找几十个团队的人抓着他们跟着你改代码。
过度设计也是基于这个准则。假设地球上有一万个中型或者大型项目,并且每个项目都有几十个工程师在工作,每个项目都需要不同的组件来互相搭配,如果不做成接口,不解耦组件,那得浪费多少工程师的时间?
当你用 Java 的时候,你就要把自己摆正到正确的位置上。这是一个更适合大型企业的语言和框架环境,方便几百几千个工程师在一起协作开发,方便让各种能力水平的人都聚到一起工作。有多少语言和框架能做到这样的?不多吧。
我给公司做团队项目,那肯定是用 Java 的。但是我要是自己写项目,或者和志同道合的人一起写,我肯定选择写 Ruby 。三个人的团队写 Java 会很不舒服,三十人的团队写 Ruby 也会很不舒服。不同的语言有不同的特长。
codingadog   
在我这个没写过 Java 项目的外行看来,面向接口编程应该是没什么问题的,准确来说是面向抽象编程,但并不是所有东西都需要抽象,以“考虑未来 /拓展”为理由产生的过度抽象是应该避免的。
关于 Getter/Setter:同 56 楼,是面向对象保持封装性的一部分,但是我个人认为如果你开发的是一个类似 Spring 这样需要一步步发展完善的大型工程项目,那封装是很重要的,反之如果只是写简单的业务逻辑,以后很可能整个 Model 都推翻重来,也不会有人在你这个项目之上再去拓展(感觉一般的 Web 项目模型都不会再作为其他项目的基础了),那么对于不需要限制修改的属性,完全可以写成 public 的。
其他内存问题我不了解,不过直觉多一个 JVM ,不管怎么都不可能和直接在对应平台上编译效果一样吧。
DOLLOR   
世界上只有两种语言:没人用的语言,和被人喷的语言(手动 doge
您需要登录后才可以回帖 登录 | 立即注册

返回顶部