问题命名接口

时间:2010-06-09 06:57:59

标签: language-agnostic naming

我有一个名为PropertyFilter的接口,用于接受Property并决定是否接受它。世界很好。

但现在接口已更改,因此实现可能会选择添加其他Property。例如,Customer属性可能会扩展为NameAddress属性。

我认为这显然不再是过滤器了,但你怎么称呼这样的东西?

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

Property -> List<Property>

如果一个空List表示不接受该属性,则一个List表示接受该属性,而一个List表示接受该属性,另一个List表示一个表示扩展的新属性(可能包括原始属性)。

4 个答案:

答案 0 :(得分:1)

  • PropertyChecker
  • PropertyValidator
  • PropertyDistillator
  • PropertyAccreditor ...

您是否已经提到了您提到的方法的名称?它也可以帮助我们找到接口的正确名称。

答案 1 :(得分:0)

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

如果它需要一个客户并对其进行分解(可能你有一个函数需要一个Customer并返回一个Name,而另一个函数返回一个地址),那么我可能称之为“访问者”。这个术语通常用于描述对象的成员函数,但我认为它也适用于此。

答案 2 :(得分:0)

如果CustomerNameAddress,则它不再是属性,而是实体

Customer属性可以是{em>引用到Customer实体,在这种情况下,您的界面的语义约定仍然适用。

答案 3 :(得分:-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扩展方法。