我在一个构造方法中写了30个参数

在我们列举了一个具有七个字段的例子，比较容易理解，现在我们来分析一下，他有什么缺点：

缺点1：反转字段，编译器不会报错

比如上面的字段里面有一个weight和一个score，都是float类型，如果再new一个Student类时，不小心写反了，编译器不会察觉。

缺点2：难以理解

这里只是七个字段，如果有十几个，我们就需要不断地去Student类中去查看，看看第几个参数应该写哪些东西，实在是比较麻烦。用户在看到这个Student(2,"愚公要移山",18,1,175,120,99)无法理解每一个字段属性代表的是什么含义。

缺点3：不想设置的参数，却不得不设置值

有时候我们的Student只想着设置ID、name和age字段，其他的无关紧要，但是这种模式必须要设置所有的属性值。

既然上面有这些缺点，我们可能还想到另外一种方式，那就是javaBean。样看起来还可以，不过这只是我自己一个一个敲出来的。实际在用的时候就知道同样恶心了，现在来总结一波他的缺点。

缺点1：构造过程中 JavaBean可能处于不一致的状态

JavaBeans 模式本身有严重的缺陷。由于构造方法在多次调用中被分割，所以在构造过程中 JavaBean 可能处于不一致的状态。该类没有通过检查构造参数参数的有效性来执行一致性的选项。在不一致的状态下尝试使用对象可能会导致与包含 bug 的代码大相径庭的错误，因此很难调试。

说一下我对其的理解，在上面的例子中，我们的student1对象被多次调用了set方法，但是可能有时候在用到这个bean时，剩下的setter方法还没有做完，于是再次调用时发现同一个javaBean呈现出了两种状态。于是处于一种不一致的状态。

缺点2：无法保证javaBean的不可变性

使用第一种模式可伸缩构造方法实例化之后不会更改可变性，所有的数据都是确定好了的。也可以保证线程安全。但是提供了setter方法，就不能保证了。比如：

（编辑：惠州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!