java - 在类构建过程中使用 setter 的缺点？

Question

请注意:我问的是缺点，而不是问优点是否胜过缺点，反之亦然，所以这不是基于意见的。

我正在学习 Java 教程，该教程建议在构造期间不要使用 setter(即使 setter 逻辑在实例的构造中有意义)。我想知道为什么这是一个坏主意。本教程稍后对继承问题做了相当模糊的提及。

此外，如果 setter 主要是验证，我是否可以将验证作为单独的函数取出，然后能够在构造函数中调用该函数，而不会遇到与直接使用 setter 相同的问题？

Answer 1

要点(这可能是您的教程试图了解继承的内容)是，当您构造对象时，如果您正在调用方法，那么如果这些 setter 在子类中被重写，那么可能会导致问题。重写版本将调用子类代码，其中子类可能尚未初始化(因为子类初始值设定项和构造函数尚未运行)，因此初始化可能会失败或产生意外后果。如果您在构造期间限制实例方法的调用，仅调用 final方法，则可以避免此问题。

有些人确实在他们的 setter 中进行了验证，但这可能不是最佳实践。可以使用注释添加验证，或将其移至单独的专用验证对象中，您可以在其中控制在什么情况下调用验证。例如，在 JPA 中，ORM 实现使用持久性实体的 getter 和 setter，并且其中的验证代码可能会造成妨碍。我建议寻找从 setter 中删除验证的方法。