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

通常，当我创建新类时，我首先创建一个新接口。我对接口的方法的命名与我希望它们的行为完全相同。我的一位同事希望这些方法名称更加抽象，即：areConditionsMet（）。原因是，他想隐藏“实现细节”

---

IMO实现细节与预期行为不同。也许有人能提供更多的见解。我的目标是与我的同事达成共识。

接口方法的名称应该让接口的用户从功能的角度毫无疑问地知道该方法打算做什么。如果实现符合这一点，那就很好了

根据您的最新评论：

听起来您需要两种方法：isModified（）和hasProperties（）。由域对象的用户（或更高层）决定是否满足特定条件

---

界面的设计还应考虑到，在发布后，它将永远不会被更改。通过说isDomainObjectModifiedHasProperties（），您在具体中设置了这是fullfilment的标准（不管将来有什么不可预见的实现）。

您的方法名称应该描述该方法的功能，而不是描述它是如何实现的。您给出的示例是一个非常糟糕的方法名称，但它比

isXGreatherThan1AndLessThan6（）好。在不知道它应该做什么的细节的情况下，我会说它应该是针对手头的问题的，但是足够通用，实现可以在不影响名称本身的情况下进行更改，也就是说，您不希望方法的名称是脆弱的。例如，
isTemperatureWithinRange（）
——它描述了我正在检查的内容，但没有描述它是如何完成的。该方法的用户应该确信，输出将反映温度是否在某个范围内——无论这是作为参数提供的还是由类的契约定义的，都是无关紧要的。
接口应该表示某种行为或能力，而不是实现它的方式。界面的用户不应该对目标的实现方式感兴趣，他们只想知道目标的完成情况

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

然而，从你的问题来看，很难说手头的确切情况是什么

如果您能提供更多详细信息，或许我可以提供额外的帮助。
您对“areConditionsMet”的称呼是什么？如果我有两个条件：假设域对象必须修改（即标志设置为true），并且它具有某些属性。我的名字应该是IsDomainObjectModifiedHasProperties（）。困难在于有些类比其他类更抽象。有些帮助器/管理器类正是按照方法所描述的那样执行的。但是你得到的抽象程度越高，我可以想象你最终会得到一个接口，方法是“doesDomainObjectSatisfyCriteria”。