我该怎样理智地命名一个"伞"类型？

Question

这"总是"困扰着我......

假设我有一个接口IFiddle和另一个接口,除了聚合几个不同的IFiddles 之外什么都不做:

public interface IFiddleFrobbler
{
    IFiddle Superior { get; }
    IFiddle Better { get; }
    IFiddle Ordinary { get; }
    IFiddle Worse { get; }
    IFiddle Crackpot { get; }
}

(具体的IFiddleFrobblers和IFiddles取决于配置,由工厂创建.)

我一再偶然发现这种"伞"类型的命名 - 我想用描述性的东西来交换"Frobbler".

• "集合","列表"和"集合"不够好,因为它不是可以枚举,添加或删除元素的集合/列表/集合.
• "经理"已经出局,因为没有管理工作 - 工厂和配置处理.
• "聚合器"听起来就像从GoF书中直接挑选出来的那样(虽然我认为它们不会破坏"demeter法则" - 这不是主题).

请赐教,我的"伞"类型的命名方案是什么？

---

编辑:正如xtofl在评论中指出的那样,实际上比我上面首次公开的语义更多.如果我改为做以下事情,我认为我的需要更清楚:

//
// Used for places where the font width might need
// to be tapered for a rendered  text to fit.
//
public interface ITaperableFont
{
    Font Font { get; }
    Boolean CanTaper { get; }

    void Taper();
}

//
// Used for rendering a simple marked-up text in
// a restricted area.
//
public interface ITaperableFonts
{
    ITaperableFont Biggest{ get; }
    ITaperableFont Big { get; }
    ITaperableFont Normal { get; }
    ITaperableFont Small { get; }
    ITaperableFont Smallest { get; }
}

事实上,我已经在上面的现实生活中将我的问题确定为一个设计缺陷,而不是一个命名问题,几个人在下面指出的气味.

Answer 1

你能用复数:IFiddles？

Answer 2

我同意你的意见,认为类,接口或抽象类很难正确.我之前使用过的一些可能的名称是:

• XXXAssistant
• CompositeXXX
• XXXCoordinator
• XXXGroup

Answer 3

我想说，您选择的名称应该取决于您想要实现的目标。在代码示例中，我会说您正在做的是设置评级，所以我可能会称之为IFiddleRating

作为一般性答案，我会说“这取决于”:)我发现用它想要做的事情来命名是个好主意，而不是它“是什么”