Java验证参数包装类中的参数

Question

我有一个类，其构造函数接受一个包含该类参数的对象（我确定这个名字很漂亮，但我不知道），我正在考虑处理验证的选项参数。

我应该在主类构造函数中进行验证，只是让参数包装类成为一个无法质疑它给出的任何值的哑容器吗？如果是这样，抛出IllegalArgumentExceptions是不错的做法，即使它是“非法”的包装类的成员，而不是对象本身？虽然我猜一个具有“非法”参数的对象本身可以被视为“非法对象”。

另一个选择似乎是在参数包装类中进行一些验证。

我不知道，对我而言，让主要类跟踪它接受的值听起来更“干净”，这听起来不像包装类的责任？然后，我可以写一个新的验证类，但听起来......不必要？如果你愿意，那就太过分了。

Answer 1

这个问题的答案完全取决于你，完全取决于你的背景，使用哪个对象等等。但你所谈论的“参数对象”被称为 bean ，你要问的是 bean验证，这可能值得谷歌搜索。

如果其他人（其他类）将使用您的“参数对象”，那么将验证放在对象本身中可能是有意义的。但话又说回来，它还取决于该对象的来源 - 来自属性文件吗？从GUI？可能是其中之一？然后，在对象外部进行验证可能更有意义，以便以合理的方式通知用户。

没有一个正确答案。

如果您决定在对象内部进行验证，则bean验证允许您使用注释来强制执行每个变量的有效性。更多信息here。

编辑：您可能还会考虑两个不同对象可能使用相同“参数对象”但对有效参数对象有完全不同的想法的情况。在这种情况下，在对象之外进行验证会更有意义。就像我说的，这完全取决于你的背景。

Answer 2

参数包装器对象是否知道它无效？其中包含的数据的有效性由其使用的上下文提供。

可以执行简单验证，例如禁止包装器对象中的null，但是接受类对参数的验证似乎是合适的。 更复杂的验证也是一种选择，但可能会限制您在其他用例中重用该对象的能力。

考虑可能有多个类接受这些参数对象的情况，其中一个接受null表示某些值而另一个不接受。{1}}。如果您明确禁止包装器中的null，那么您已经在允许或允许它的类中删除了该用例。

同样，它完全取决于您以及您打算如何使用这些对象。验证必须在某个地方完成，问题是，你想对谁负责以及你希望它是如何可维护的？

Answer 3

虽然它更像是主观的，但我认为在Wrapper类中进行验证会更好。 无论是包装器还是main / actual，Object都是一个Object，它的完整性应该与创建一起保持。因此，在将包装器对象传递给主类之前保持其完整性是一种很好的做法。