8.2 例子：配置参数

配置参数是一个将复杂性向上而不是向下移动的例子。一个类可以导出一些控制其行为的参数，而不是在内部确定特定行为，例如缓存的大小或在放弃之前重试请求的次数。该类的用户必须为这些参数指定适当的值。配置参数在当今的系统中变得非常流行；有些系统有数百个配置参数。

倡导者认为，配置参数是好的，因为它们允许用户根据他们的特殊要求和工作负载调整系统。在某些情况下，低级别的基础设施代码很难知道要应用的最佳策略，而用户对他们的领域要熟悉得多。例如，用户可能知道一些请求比其他请求在时间上更为紧迫，因此用户为这些请求指定更高的优先级是有意义的。在这样的情况下，配置参数可以在更广泛的领域中带来更好的性能。

然而，配置参数也提供了一个简单的借口，可以避免处理重要的问题并把它们转交给其他人。在许多情况下，用户或管理员很难或不可能确定参数的正确值。在其他情况下，只要在系统实现中做一点额外的工作，就能自动确定正确的值。考虑一个必须处理丢失数据包的网络协议。如果它发送了一个请求，但在一定时间内没有收到响应，它就会重新发送请求。确定重试间隔的一种方法是引入一个配置参数。然而，传输协议可以通过测量成功的请求的响应时间，然后使用其倍数作为重试间隔，自行计算出一个合理的值。这种方法降低了复杂性，使用户不必再去计算正确的重试间隔。它的另一个优点是动态计算重试间隔时间，所以如果操作条件发生变化，它将自动调整。相比之下，配置参数很容易过时。

因此，你应该尽可能地避免配置参数。在导出一个配置参数之前，要问自己。“用户（或更高级别的模块）是否能够确定一个比我们在这里确定的更好的值？” 当你创建配置参数时，看看你是否能自动计算出合理的默认值，这样用户就只需要在特殊情况下提供值。理想情况下，每个模块都应该完全解决一个问题；配置参数会导致一个不完整的解决方案，这增加了系统的复杂性。