命名接口的问题答案

【问题标题】：Problem Naming an Interface命名接口的问题
【发布时间】：2010-06-09 06:57:58
【问题描述】：

我有一个名为PropertyFilter 的接口，它曾经接受Property 并决定是否接受它。世界是美好的。

但现在接口发生了变化，因此实现可以选择添加额外的Propertys。例如，Customer 属性可能会扩展为 Name 和 Address 属性。

我认为这显然不再是过滤器了，但是你怎么称呼这种东西呢？

澄清一下：所谓的过滤器几乎是一种带有签名的方法

Property -> List<Property>

一个空列表表示不接受该属性，一个具有完全输入属性的列表表示接受该属性，一个带有新属性（可能包括原始属性）的列表表示扩展。

【问题讨论】：

对我来说仍然像是一个过滤器。 Filter[T] 通常是 T -> Boolean 的某个函数，这似乎仍然是。
为什么要关心PropertyFilter中的Property？为什么不简单地拥有一个过滤器接口？
@mathk 我们选择 PropertyFilter 而不是 Filter，因为我们的代码库中已经有两个 Filter，并且我们使用的库中大约有数以亿计的过滤器。但问题实际上是关于名称的过滤器部分。
@Travis 我更新了问题以表明我们拥有的声明与过滤器的预期声明不匹配。

【解决方案1】：

您是否已经为您提到的方法命名？它也可以帮助我们为接口找到合适的名称。

【讨论】：

该方法当前被称为'expand'
好的，所以接口具有验证和扩展属性的混合责任。您可以使用更通用的名称，例如 PropertyManager 或 PropertyHandler。或者，您可以将 2 个职责拆分为 2 个单独的类，PropertyValidator 和 PropertyExpander，其中一个调用另一个。我想解决方案取决于客户端代码如何使用接口，以及客户端代码是否知道验证方面或扩展方面（或两者）。

【解决方案2】：

我不太确定你的新功能是做什么的。如果它仍然返回布尔值，则返回布尔值的函数的另一个名称是“谓词”。

如果它接受一个客户并分解它（也许你有一个函数接受一个客户并返回一个名称，另一个函数返回一个地址），那么我可以称它们为“访问器”。该术语通常用于描述对象的成员函数，但我认为它也适用于此。

【讨论】：

【解决方案3】：

如果Customer 具有Name 和Address，则它不再是属性，而是实体。

Customer 属性可以是Customer 实体的引用，在这种情况下，您的接口的语义约定仍然适用。

【讨论】：

【解决方案4】：

我会添加一个名为 validate 的方法到 Property 并带有签名：

PropertyFilter -> Bool

validate 的默认实现只是将this（属性）传递给过滤器并返回结果：

def validate (filter: PropertyFilter) = filter (this)

作为复合属性，Customer 覆盖 validate，根据其复合属性实现它：

override def validate (filter: PropertyFilter) = name.validate (filter) && address.validate (filter)

这样，每个Property 都可以描述如何将任何给定的PropertyFilter 应用于自身。我认为您应该避免使用 List 扩展方法。

【讨论】：