多参数方法的问题

相信很多人曾经都写过多参数的构造方法，就像下面示例的代码。

当想要创建一个给全部属性赋值的实例的时候，就会利用这个多参数的构造方法。但是，当类的属性特别多的时候，你还会这么写吗？

如果你写了一个包含N个参数的多参数构造方法，当创建实例的时候，是不是特别谨慎的在大脑里记着第几个参数是给哪个属性赋值的，生怕给弄错了，当然类型不对的时候，编译器还会友善的提醒赋值错了，但对那些类型相同的属性，如果不小心颠倒了两个参数的顺序，编译器也爱莫能助了，程序运行起来也不会报错，就是执行结果不是期望值。

如果有人写了一个包含N个参数的多参数构造方法并打包后提供给你使用，又如果你看不到方法的源代码或Javadoc，更不巧这些参数的名称很随意(例如arg1、arg2...argN等)，你会不会恶狠狠的在背后慰问代码的作者。

这种多参数的构造方法，当参数的个数小于等于3的时候不是很糟糕，但是，随着参数个数越来越多的时候，这种构造实例的方法就会失去控制，变得难以使用。

看到这里，也许有人会说，当然不会写一个包含N个参数的多参数构造方法，可以使用默认的构造方法创建实例，然后使用setter方法给各个属性一一赋值，就像下面示例代码这样。

不得不说这种方式创建实例很容易，产生的代码也易读，同时也是使用最频繁的方式。但是，它有很严重的缺点，就是一旦提供了属性的setter方法，则代表你可以在任何地方、任何时候给某个或某些属性单独赋值，致使实例的构造被分散到各个角落，最终可能会导致连代码原作者都不知道在哪里给某个属性“又”赋了值，导致实例数据不一致，调试查找问题也很麻烦。

这里笔者分享一个曾经经历的，使用setter方法给属性赋值的坑。很早之前使用Hibernate进行CRUD操作，大家都知道Hibernate的get和load方法查询出的实体对象会被缓存，并且是处于持久态的，持久态的实体无论你显示调用update操作或不调用，只要它在一个事务中，当事务被提交的时候，它会比较缓存中实体数据和快照区中的实体数据，将变化主动更新到数据库中，坑就出现在这里。查询出来的实体对象被当做参数传递到了其它方法中，而此时为了某些操作的需要，调用了某个属性的setter方法赋值，但是并没有显示调用update方法，导致看上去每次执行完查询数据就被自动更新，查找原因起来不是很容易。这就是使用setter方法导致的赋值分散的问题。

相信大多数人都写过或使用过多参数的普通方法，就像下面示例的代码。

可能会有人觉得这没什么，不就5个参数嘛！没事，就这么写！对于这种觉悟，笔者只能说你试试10个参数或更多，保证你会精神崩溃，即使你能忍受，调用你方法的同事保证会在背后慰问你。

这种写法也同样有上面多参数构造方法的问题，参数多了方法就会失去控制，难以使用。

多参数方法指南

对于多参数的构造方法，使用Builder模式代替，就像下面的示例代码。

从实例代码可以看到，使用Builder模式构造实例根本不需要费尽心思的牢记参数列表，想给哪个属性赋值直接显示的给哪个属性赋值，再也不怕赋错值，代码清晰明了！注意看示例代码中，实际给bank实例属性赋值的地方，即下面的代码。

可以看到在Bank的构造方法里集中给各个属性赋值，并不会分散赋值。如果想再次给某个属性赋值，可以像示例代码这样。

对于普通方法，如果方法参数的个数大于三，将这些参数抽象成一个类，这些参数就是类的属性，然后在多参数的方法中，使用这个类代替这些参数，同时在这个参数类中提供Builder模式代码用于创建类的实例，就像下面的示例代码。