业务逻辑复杂的时候,各种 != null 多到数不清,代码也变得不太容易阅读。
大家在项目中是如何规范 null 的使用的?
比如所有属性值都有默认值?数据库字段不能为空?
1
knightdf 2016-04-25 10:33:53 +08:00
Option
|
2
cloudzhou 2016-04-25 10:43:01 +08:00
比如所有属性值都有默认值,数据库字段不能为空。
确实就是很好的方式 |
3
xujif 2016-04-25 10:45:11 +08:00
数据库判空是正常的,主要是一些 list , map 之类 返回 null 代替返回 new 就好了
|
4
Lonely 2016-04-25 10:46:09 +08:00 via iPhone 1
guava
|
5
sudoz 2016-04-25 10:48:37 +08:00
同建议使用 guava
|
6
darasion 2016-04-25 10:48:59 +08:00 1
我认为,习惯了之后,并不烦人。
而且还有各种好处。其中最大的好处,就是写完各种 check null 代码后获得的成就感,虽然对业务逻辑的开发进度没什么促进。但是你做完了好多不得不做工作,这对建立完成项目的信心有很大帮助。 别小看信心哦,有时候你业务代码憋不出来的时候,写写这种代码,会很愉快,至少你能体验到整个项目正在推进的感觉。 |
7
specita 2016-04-25 10:52:36 +08:00
单纯判断 null 还好吧..null+empty 会比较烦..可以用 java8 optional , guava 也有
|
8
saberpowermo 2016-04-25 10:56:12 +08:00
@darasion 完全支持。
|
9
vm 2016-04-25 11:01:04 +08:00 via Android
|
10
codeyung 2016-04-25 11:21:03 +08:00
一般默认值数据库尽量不要有 null
|
11
zhouquanbest 2016-04-25 11:24:17 +08:00
君不见 因为 null 前端做防御编程时有多痛苦
所有字段检验 null null 逻辑处理 parse error 处理 所以还是拥抱变化 切到 Kotlin 吧 |
12
ChoateYao 2016-04-25 11:38:42 +08:00
重构:引入 Null 对象 P260
|
13
hooluupog 2016-04-25 11:47:39 +08:00
guava 目前是最靠谱的选择。
|
14
ffffwh 2016-04-25 11:48:18 +08:00 via Android
|
15
armstrong 2016-04-25 11:49:56 +08:00
使用 Apache Common Lang3 的话,可以用这个, StringUtils.isBlank(), StringUtils.isNotBlank() ;
使用 Guava 的话,使用 Optional |
16
springzero 2016-04-25 11:52:37 +08:00
不要容易阅读。。。这也夸张了吧 (!= null 代表的含义好像就一个) 这叫防御式编程。。
|
17
westlinkin 2016-04-25 11:54:59 +08:00
转用 Kotlin , null-safe 的
|
18
gogohigh 2016-04-25 12:02:11 +08:00
java8 Optional
|
19
gogohigh 2016-04-25 12:02:11 +08:00
java8 Optional
|
20
hantsy 2016-04-25 12:14:01 +08:00
java 8 有 Optional
|
21
zhujinliang 2016-04-25 12:18:02 +08:00 via iPhone
golang 笑而不语
|
22
LINEX OP @zhujinliang 但是 golang 有 err != nil 啊,哈哈哈
|
23
LINEX OP @springzero 代码里出现很多这种东西挺烦的,有时候不得不一层套着一层,出现好多嵌套层。。。。。
|
24
lijsf 2016-04-25 13:12:23 +08:00
java 的 null 还好了, C/C++就得跪了。
|
25
monkeylyf 2016-04-25 13:12:50 +08:00
“ Null is the worse mistake ever made in computer science history."
|
27
slixurd 2016-04-25 13:14:27 +08:00
不判断 null 的后果就是操作 object 时直接 NullPointerException 了
自己写个 Validator 就好了,尽量写在 Model 里面,不写在 Service/Controller 层。 |
28
hooluupog 2016-04-25 13:34:19 +08:00
@LINEX 但 Go 有默认值,很多数据结构默认值就不允许为 nil ,根本没有 java/c++里面这种 null 带来的比较严重的问题,只是写起来很罗嗦,需要改进。但这个问题不是 null 最大的危害所在。你只觉得 java 里的 null 判断比较罗嗦,但其实仅仅是罗嗦的话,这个问题也就不会是 one billion dollar mistake 了。
|
31
Patiencec 2016-04-25 14:53:32 +08:00
好吧,偏个题。 java 不熟悉不知道有没有可选类型
|
32
tomoya92 2016-04-25 14:57:57 +08:00 via Android
|
34
cloudhuang 2016-04-25 20:28:02 +08:00
推荐这个 blog http://www.yegor256.com/2014/05/13/why-null-is-bad.html ,列举了在开发中常见的几种 null 的场景以及如何避免
|
35
huiyue 2016-04-25 20:55:22 +08:00
目前为止, Java 中我针对可能的 null 都是老老实实判断的。
|
36
eimsteim 2016-04-25 21:39:42 +08:00
并未觉得 null 有什么不好用的地方,有时候用 null 来做异常判断会更方便。
|
37
wucao219101 2016-04-25 22:08:39 +08:00
|
38
caixiexin 2016-04-25 22:12:46 +08:00 via Android
用 google 的 guava 包
|
39
Narcissu5 2016-04-25 22:13:51 +08:00
|
40
Narcissu5 2016-04-25 22:21:51 +08:00
按最小开放原则,方法尽量 private ,私有方法可以在编译时检查是否有 null ,通过检查就不用再 check 了,就酱~
|
41
karloku 2016-04-25 22:23:50 +08:00
https://en.wikipedia.org/wiki/Null_Object_pattern
confident coding 常用的一种模式, 如果是写自己东西的话可以避免 null, 而是甩出一些空值对象或者 dummy object. 不过在稍微大点的项目里对 null 还是没什么很好的办法, 就算你自己的包 confident 了, 还是要面对别人的包里丢出来的 null... |
43
hinkal 2016-04-26 00:02:20 +08:00
搜索 Null Object 设计模式
|
44
georgema1982 2016-04-26 01:15:28 +08:00
所以我现在很烦纯 java ,更加喜欢用 groovy
|
45
ffffwh 2016-04-26 02:20:41 +08:00 via Android
@Narcissu5
“ null 在类型系统中开了个洞”。实际上 Java 里所有的 X 类型都可以读作 Maybe_X 。 Swift 没 null ,有 optional 。 Optional 一般不判空,而是一路.map ,一步为空则后续自动为空,最后才判空或者.orElse 。实际业务逻辑里是否好用不明。 monad 啥的我也不懂就不扯了,丢篇文章 http://fsharpforfunandprofit.com/rop/ |
46
ivanlw 2016-04-26 05:19:14 +08:00
@georgema1982 From Groovy creator James Strachan:
"I can honestly say if someone had shown me the Programming Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy. " |
47
shawshi 2016-04-26 09:11:27 +08:00
尽量在输入录入的时候,就加上非空验证吧
|
48
linux40 2016-04-26 09:31:02 +08:00 via Android
Null 对象确实是一种解决方式。
|
49
georgema1982 2016-04-27 00:17:02 +08:00
@ivanlw 不知到你为什么还在引用老黄历, groovy 早就在后 James Strachan 时代了,他说什么并不重要
|