接口内的方法命名应该具体还是抽象?

时间:2010-06-22 11:34:10

标签: interface naming-conventions method-names

通常,当我创建新类时,我首先创建一个新接口。我完全按照我希望他们的行为命名我的界面方法。我的同事更喜欢这些方法名称更抽象,即:areConditionsMet()。原因是,他想隐藏“实施细节”。

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

3 个答案:

答案 0 :(得分:1)

您的方法名称应该描述该方法的作用,而不是它是如何做到的。您给出的示例是一个非常差的方法名称,但它比isXGreatherThan1AndLessThan6()更好。在不知道它应该做什么的细节的情况下,我会说它应该特定于手头的问题,但总的来说,实现可以在不影响名称本身的情况下改变,即,您不需要方法的名称要脆。一个例子可能是isTemperatureWithinRange() - 它描述了我正在检查的内容,但没有描述它是如何完成的。该方法的用户应该确信输出将反映温度是否在一定范围内 - 无论是作为论据提供还是由类的合同定义,都是无关紧要的。

答案 1 :(得分:0)

接口方法的名称应该使界面的用户无疑从功能的角度来看该方法的建议。如果实现匹配那么好,那就好了。

根据您更新的评论:

听起来我需要两种方法: isModified() hasProperties()。将其留给域对象的用户(或更高层)以确定是否满足特定条件。

界面也应该设计为在发布之后它将永远不会更改。通过说isDomainObjectModifiedAndHasProperties(),您具体地设置这是 fullfilment的标准(无论未来任何未实现的实现)。

答案 2 :(得分:0)

接口应代表某些行为或能力,而不是它的完成方式。接口的用户不应该对目标的实现方式感兴趣,他们只是想知道它的完成情况。

出于该确切原因,实施问题不应包含在方法名称中。由于此方法或使用的技术而更新的表的名称与域对象的方法名称无关。

但是从您的问题来看,很难说具体的案例是什么。

如果您可以提供更多详细信息,或许我可以提供额外的帮助。