接口中的方法命名应该是具体的还是抽象的？
通常，当我创建新类时，我首先创建一个新接口。我完全按照我希望的方式命名接口的方法。我的一位同事喜欢让这些方法名称更抽象，即：areConditionsMet()。原因是，他想隐藏‘实施细节’。
IMO 实施细节与预期行为不同。谁能提供更多见解。我的目标是与同事达成共识。
Often when I create new classes, I first create a new interface. I name the methods of my interface exactly as I would like them to behave. A colleague of mine prefers to have these method names being more abstract, ie: areConditionsMet(). The reason, he wants to hide the 'implementation details'.
IMO implementation details are different from the expected behavior. Could anyone perhaps give more insight. My goal is to reach a common ground with my colleague.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您的方法名称应该描述该方法的用途，但不描述它是如何做的。您给出的示例是一个非常糟糕的方法名称，但它比
isXGreatherThan1AndLessThan6()更好。在不知道它应该做什么的细节的情况下，我想说它应该针对当前的问题，但足够通用，可以在不影响名称本身的情况下更改实现，即您不想要方法的名称变脆。一个例子可能是isTemperatureWithinRange()- 它描述了我正在检查的内容，但没有描述它是如何完成的。该方法的用户应该确信输出将反映温度是否在某个范围内——无论这是作为参数提供还是由类的合同定义，都不重要。Your method names should describe what the method does, but not how it does it. The example you gave is a pretty poor method name, but it's better than
isXGreatherThan1AndLessThan6(). Without knowing the details about what it should do, I would say that it should be specific to the problem at hand, but general enough that the implementation could change without affecting the name itself, i.e., you don't want the name of the method to be brittle. An example might beisTemperatureWithinRange()- that describes what I'm checking but doesn't describe how it's accomplished. The user of the method should be confident that the output will reflect whether the temperature is within a certain range -- whether this is supplied as an argument or defined by the contract of the class, is immaterial.接口应该代表某种行为或功能，而不是实现它的方式。界面的用户不应该对实现目标的方式感兴趣，他们只想知道目标的完成情况。
正是出于这个原因，实现问题不应包含在方法名称中。由于此方法或所使用的技术而更新的表的名称与域对象的方法名称无关。
但从你的问题来看，很难判断当前的具体情况是什么。
如果您可以提供更多详细信息，也许我可以提供额外的帮助。
Interfaces should represent some behavior or capability and not the way it is to be accomplished. Users of interfaces should not be interested in the way a target is achieved, they just want to know its done.
Implementation issues should not be included within the name of methods for that exact reason. The name of the table updated as a result of this method or the technology used has nothing to do in your domain object's method's name.
However from your question it is hard to say what is the exact case at hand.
If you could provide more details perhaps i could provide an additional help.
接口方法的名称应该让接口的用户从功能角度对该方法的用途毫无疑问。如果实现与此相符，那就太好了。
根据您更新的评论：
在我看来，您需要两种方法：isModified()和hasProperties()。将其留给域对象的用户（或更高层）来确定是否满足特定标准。
界面设计还应该考虑到发布后将永远改变。通过说 isDomainObjectModifiedAndHasProperties()，您可以具体设置这是满足的标准（无论未来是否有任何不可预见的实现）。
The names of your interface methods should leave the user of the interface in no doubt about what the method proposes to do from a functional perspective. If the implementation matches that, well and good.
Based on your updated comments:
Sounds to me like you need two methods: isModified() and hasProperties(). Leave it up to the user (or higher layer) of the domain object to determine if a particular criteria is fulfilled.
An interface should also be designed with the view that after it is released it will never be changed. By saying isDomainObjectModifiedAndHasProperties() you are setting in concrete that this is the criteria of fullfilment (regardless of any future unforseen implementation).