使用一种以常量作为参数的方法，而不是几种方法 [英] Using one method with constants as parameters versus several methods

问题描述

在肯特·贝克(Kent Beck)的实施模式中，可以阅读

In Kent Beck's Implementation Patterns, one can read

常量的常见用法是 在其中传达消息的变化 接口.例如，以居中 您可以调用的文字 setJustification(Justification.CENTERED). 这种API的优点之一是 您可以添加新的 通过添加新的现有方法 不变的常数 实施者.但是，这些消息 沟通不如拥有 每个变体的单独方法.在 这种风格，上面的信息是 justifyCentered().一个接口，其中 方法的所有调用都具有 作为参数的文字常量可以是 通过给它单独的方法来改善 每个常数值."

"A common use of constants is to communicate variations of a message in an interface. For example, to center text you could invoke setJustification(Justification.CENTERED). One advantage of this style of API is that you can add new variants of existing methods by adding new constants without breaking implementors. However, these messages don't communicate as well as having a separate method for each variation. In this style, the message above would be justifyCentered(). An interface where all invocations of a method have literal constants as arguments can be improved by giving it separate methods for each constant value."

这是为什么?通常，当我编码时，我注意到我有几个类似的无参数方法，可以将它们简化为一个带有参数的方法，如以下示例所示，

Why is this? Generally when I'm coding and I notice that I have a couple of similar parameterless methods that could be reduced to just one, with an argument, like in the following example,

void justifyRight()
void justifyLeft()
void justifyCentered()

我通常会做与肯特建议相反的事情，那就是将其分组为

I'd generally do just the opposite of what Kent advices, which would be to group it into

setJustification(Justification justification)

您通常如何处理这种情况?这是完全主观的还是真的有很强烈的理由让我看不到肯特对这个问题的看法?

How do you usually handle this situation? Is this totally subjective or there is really a very strong reason that I can't see in favour of Kent's view of this matter?

谢谢

推荐答案

文件访问方法通常具有有关读/写模式，是否创建不存在的文件，安全属性，锁定模式等参数.想象一下，如果您要为每个有效的参数组合创建单独的方法，您将拥有的方法数量！

File access methods usually have parameters regarding read/write mode, whether to create non-existing files, security attributes, locking modes and so on. Imagine the amount of methods you'd have if you'd create a separate method for each valid combination of parameters!

我已经强调了支持单独方法的最大论点.因为您对API有严格的控制，所以它是故障安全的.如果您不公开这样的参数，则调用者无法传入无效的参数或无效的参数组合.这也意味着不太复杂的参数验证.

I've highlighted the biggest argument in favor of separate methods; it's fail-safe because you have strict control over the API. The caller cannot pass in invalid arguments, or invalid combinations of parameters, if you don't expose such parameters. This also implies less complex parameter validation.

但是，我不赞成这种做法. API应该经过精心设计，并且应该更改为尽可能少.肯特·贝克(Kent Beck)关于突破性的API更改:

However, I'm not in favor of this practice. API's should be well-designed and should change as little as possible. Kent Beck on breaking API changes:

[参数化方法]的一个优点是，您可以通过添加新的常量来添加现有方法的新变体，而不会破坏实现器.

One advantage of [parameterized methods] is that you can add new variants of existing methods by adding new constants without breaking implementors.

他赞成使用单独方法的论点是:

His argument in favor of separate methods is:

但是，[参数化方法]并没有针对每种变体使用单独的方法进行通信.

However, [parameterized methods] don't communicate as well as having a separate method for each variation.

我不同意.方法参数可以是可读的.特别是与命名参数结合使用时，多种语言都支持该功能.此外，单独的方法会导致API混乱.

I disagree. Method parameters can be just as readable. Especially in combination with named parameters, a feature which is supported by several languages. Besides, separate methods would result in a cluttered API.

这篇关于使用一种以常量作为参数的方法，而不是几种方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！