推荐关注
› Meteor
› JSLint - a JavaScript code quality tool
› jsFiddle
› D3.js
› WebStorm
推荐书目
› JavaScript 权威指南第 5 版
› Closure: The Definitive Guide
› Closure: The Definitive Guide
相比 JavaScript 社区的 DRY，我可能更喜欢 Java 社区的“RY”
Cbdy · 2020-01-13 20:54:32 +08:00 · 2311 次点击这是一个创建于 1558 天前的主题，其中的信息可能已经有所发展或是发生改变。
6 条回复 • 2020-01-14 13:49:40 +08:00
 |
1
lihongjie0209 2020-01-13 21:05:57 +08:00
这是 Java 没有模块化的锅。很多时候 public 只是在当前模块内 public， 但是在之前的 Java 中， 这是在整个 JVM 中 public， 所以会导致内部的很多实现类 util 类暴露出去， 后面支持模块化之后可以自己定义需要暴露的类和接口， 会好一点。
同时作为一个第三方包， 应该尽量少的有别的依赖， 比如很多 StringUtil 都是在特定项目中有意义，并不是类似 common 中的一样提供一个通用的 StringUtil， 所以也没必要因为一个工具类引入一个第三方 jar 包。 |
 |
2
pursuer 2020-01-13 21:23:58 +08:00
当需要造个轮子的时候，搜一下类，说不定轮子都不用造了？哈哈哈。原本的 default 访问级别就是限定同一个包内使用，但是不少项目为了跨包用都直接 public 了。大部分 IDE 都支持正则屏蔽特定包下的自动补全，所以感觉影响也不大
|
 |
3
hronro 2020-01-13 22:27:58 +08:00  1
JavaScript 项目通常是对编译后大小敏感的，如果每个第三方包都实现一些对 String 封装的类似逻辑，最后编译出来的整个大小会膨胀很多
|
 |
4
chendy 2020-01-13 22:46:39 +08:00
也是没办法，总不能到处都是 (str != null && !str.isEmpty())…
|
 |
5
HuHui 2020-01-13 22:49:02 +08:00 via Android
node_module 显然更先进点
|
 |
6
SpencerCJH 2020-01-14 13:49:40 +08:00
用 common-lang3 的那个（逃
|
Select Language