网站制作素材,绿色商城网站模板,百度seo代做,一个网络空间做两个网站多参数方法的问题相信很多人曾经都写过多参数的构造方法#xff0c;就像下面示例的代码。当想要创建一个给全部属性赋值的实例的时候#xff0c;就会利用这个多参数的构造方法。但是#xff0c;当类的属性特别多的时候#xff0c;你还会这么写吗#xff1f;如果你写了一个…多参数方法的问题相信很多人曾经都写过多参数的构造方法就像下面示例的代码。当想要创建一个给全部属性赋值的实例的时候就会利用这个多参数的构造方法。但是当类的属性特别多的时候你还会这么写吗如果你写了一个包含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模式代码用于创建类的实例就像下面的示例代码。