接口中的方法命名应该具体还是抽象？

通常当我创建新类时，我首先创建一个新界面。我完全按照我希望他们的行为来命名我的界面的方法。我的同事倾向于使这些方法名称更抽象，即：areConditionsMet（）。原因是，他想隐藏“实施细节”。接口中的方法命名应该具体还是抽象？

IMO实施细节与预期行为不同。任何人都可以提供更多的见解。我的目标是与我的同事达成共识。

2010-06-22 Stefan Hendriks

'areConditionsMet'是什么名字？ – 2010-06-22 11:37:17

如果我有两个条件：可以说域对象必须被修改（即标志被设置为true）并且它具有某些属性。我的名字是isDomainObjectModifiedAndHasProperties（）。困难在于有些类比其他类更抽象。一些助手/经理类完全按照该方法描述的内容来执行。但是，更抽象的，我可以想象你最终会用一个接口，方法“doesDomainObjectSatisfyCriteria”。 – 2010-06-22 12:48:28

您的方法名称应该描述该方法的作用，但不是它如何做。你给的例子是一个非常糟糕的方法名称，但它比isXGreatherThan1AndLessThan6()好。在不知道应该做什么的细节的情况下，我会说它应该是针对手头问题的具体情况，但通用性足以使实现可以在不影响名称本身的情况下进行更改，也就是说，您不需要方法的名称变脆。一个例子可能是isTemperatureWithinRange()--它描述了我正在检查的内容，但没有描述它是如何完成的。该方法的用户应该确信输出将反映温度是否在一定范围内 - 无论这是作为参数提供的还是由班级的合同定义的，都不重要。

来源

2010-06-22 11:45:40 tvanfosson

接口方法的名称应使接口的用户保留毫无疑问有关该方法从功能角度提出的建议。如果实现相符，那就很好。

根据您的更新评论：

听起来好像需要两个方法：isModified（）和hasProperties（）。将其留给域对象的用户（或更高层）来确定是否满足特定标准。

一个接口也应该被设计为在它被释放之后将会被从不改变。通过说isDomainObjectModifiedAndHasProperties（）您具体设置，这是 fullfilment的标准（不管未来未预见的实现）。

来源

2010-06-22 11:37:38

接口应该代表一些行为或能力，而不是它要完成的方式。接口用户不应该对目标的实现方式感兴趣，他们只是想知道它的完成。出于这个确切原因，执行问题不应包含在方法的名称中。由于此方法或使用的技术而更新的表的名称在您的域对象的方法名称中无关。

但是从你的问题来看，很难说清楚究竟是什么。

如果您可以提供更多的细节，也许我可以提供额外的帮助。

来源

2010-06-22 11:51:27 AlonEl

接口中的方法命名应该具体还是抽象？

回答

相关问题