mirror of
https://github.com/sjsdfg/effective-java-3rd-chinese.git
synced 2025-01-01 07:50:33 +08:00
Update 02. 当构造方法参数过多时使用builder模式.md
This commit is contained in:
parent
e57b0fac54
commit
4c68a9b3d1
@ -1,6 +1,5 @@
|
||||
# 2. 当构造方法参数过多时使用 builder 模式
|
||||
|
||||
---
|
||||
|
||||
静态工厂和构造方法都有一个限制:它们不能很好地扩展到很多可选参数的情景。请考虑一个代表包装食品上的营养成分标签的例子。这些标签有几个必需的属性——每次建议的摄入量,每罐的份量和每份卡路里 ,以及超过 20 个可选的属性——总脂肪、饱和脂肪、反式脂肪、胆固醇、钠等等。大多数产品都有非零值,只有少数几个可选属性。
|
||||
|
||||
@ -286,5 +285,3 @@ Calzone calzone = new Calzone.Builder()
|
||||
Builder 模式也有缺点。为了创建对象,首先必须创建它的 builder。虽然创建这个 builder 的成本在实践中不太可能被注意到,但在性能关键的情况下可能会出现问题。而且,builder 模式比伸缩构造方法模式更冗长,因此只有在有足够的参数时才值得使用它,比如四个或更多。但是请记住,如果希望在将来添加更多的参数。但是,如果从构造方法或静态工厂开始,并切换到 builder,当类演化到参数数量失控的时候,过时的构造方法或静态工厂就会面临尴尬的处境。因此,所以,最好从一开始就创建一个 builder。
|
||||
|
||||
总而言之,当设计类的构造方法或静态工厂的参数超过几个时,Builder 模式是一个不错的选择,特别是如果许多参数是可选的或相同类型的。客户端代码比使用伸缩构造方法(telescoping constructors)更容易读写,并且 builder 比 JavaBeans 更安全。
|
||||
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user