命名接口的问题

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

但是现在界面已更改，因此实施可能会选择添加其他Property s。例如，Customer属性可能会扩展为Name和Address属性。

我认为这很明显，这不是一个过滤器了，但你会怎么称呼这样的事情？

为了澄清：所谓的过滤器是一个很值得与签名

Property -> List<Property>

法用表示空List不接受物业，以准确地输入属性，代表接受属性和列表的列表新的属性（可能包括原始属性）表示扩展。

来源

2010-06-09 Jens Schauder

仍然看起来像一个过滤器给我。一个'Filter [T]'通常是一些函数'T - > Boolean'，这似乎仍然是。 – 2010-06-09 07:01:38

为什么你关心PropertyFilter中的Property？为什么不简单地使用Filter接口？ – mathk 2010-06-09 11:28:29

@mathk我们选择Filter上的PropertyFilter，因为在我们的代码库中已经有两个过滤器，而我们使用的库中有两个过滤器。但问题实际上是名称的Filter部分。 – 2010-06-09 20:39:19

PropertyChecker
PropertyValidator
PropertyDistillator
PropertyAccreditor ...

你已经为你所提到的方法的名字吗？它可以帮助我们为界面找到一个合适的名称。

来源

2010-06-21 09:52:25 guillaume31

该方法目前被称为'扩展' – 2010-06-21 21:02:26

行，所以界面有验证和扩展属性的混合责任。您可以使用更一般的名称，如PropertyManager或PropertyHandler。或者，您可以将2个职责分成两个独立的类，PropertyValidator和PropertyExpander，其中一个调用另一个类。我想解决方案取决于客户端代码如何使用接口，以及客户端代码是否知道验证方面或扩展方面（或两者）。 – guillaume31 2010-06-22 13:09:27

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

如果需要一个Customer并分解它（也许你有一个函数需要一个Customer并返回一个Name，另一个函数返回一个Address），那么我可以称它们为“访问器”。这个术语通常用来描述一个对象的成员函数，但我认为它也适用于这里。

来源

2010-06-09 07:19:42 archbishop

看到我更新的问题，谓词不适合，我不认为访问器适合... – 2010-06-09 20:42:50

如果Customer有Name和和Address的它已经不再是一个财产，而是实体。

的Customer财产可能是一个参考到Customer实体，在这种情况下，你的接口语义约定仍然适用。

来源

2010-06-09 07:28:37

-1

我会添加一个名为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扩展方法。

来源

2010-06-21 09:59:55

命名接口的问题

回答

相关问题