The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
你是否检查你的方法的输入参数的有效性？我不检查。我过去会检查，但现在不再检查了。当参数无效时，我只是让我的方法崩溃，出现空指针和其他异常。这听起来可能不合逻辑，但只是在开始阶段。我建议你使用“验证装饰器”来代替。
让我们来看一个相当典型的Java例子：
还挺防御性的，对吧？如果我们去除这些验证，代码会变得更短，但是如果客户端提供了NULL，代码将会崩溃并显示令人困惑的错误信息。而且，如果文件已经存在，我们的Report将会悄悄地覆盖它。相当危险，对吧？
是的，我们必须保护自己，我们必须做好防御。
但是不是这样，不是通过用与其核心功能无关的验证来膨胀类。相反，我们应该使用装饰器来进行验证。下面是具体做法。首先，必须有一个接口Report：
然后，一个实现核心功能的类。
最后，还有一些装饰器将保护我们：
现在，客户端可以通过执行特定任务的装饰器来组合一个复杂的对象。核心对象将负责报告，而装饰器将验证参数。
我们通过这种方法实现了什么？首先，最重要的是：更小的对象。而且较小的对象总是意味着更高的可维护性。无论我们将来创造多少个验证，我们的DefaultReport类始终保持较小。我们需要验证的事物越多，我们就会创建越多的验证装饰器。它们都将是小而有凝聚力的。我们将能够以不同的组合方式将它们放在一起。
除此之外，这种方法使我们的代码更加可重用，因为类执行的操作很少，并且默认情况下不进行自我保护。虽然自我保护是一个重要的特性，但我们将使用验证装饰器。但这并不总是适用的。有时验证在时间和内存方面太昂贵，我们可能想直接使用不进行自我保护的对象进行操作。
出于同样的原因，我决定不再使用Java验证API。它的注解使得类变得冗长而缺乏凝聚力。我改用验证装饰器。
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-17 at 16:50
