How should I name an "umbrella" type sanely?

Question

This has "always" bothered me...

Let's say I have an interface IFiddle and another interface that does nothing more than aggregate several distinct IFiddles:

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

(The concrete IFiddleFrobblers and IFiddles depend on configurations and are created by a factory.)

I repeatedly stumble on the naming of such "umbrella" types - I want to exchange the "Frobbler" with something descriptive.

• "Collection", "List" and "Set" aren't good enough, in the sense that it's not a collection/list/set where elements can be enumerated, added or removed.
• "Manager" is out, because there's no management being done - the factory and configurations handle that.
• "Aggregator" makes it sound like picked straight from the GoF book (although I don't think they would break "the law of demeter" - that's out of topic here).

Please, enlighten me, what's a good naming scheme for my "umbrella" types?

---

Edit: As xtofl pointed out in a comment, there's actually more semantics to this than I first exposed above. If I instead do the following, I think my need is clearer:

//
// 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; }
}

In fact, I've identified my problem in the real-life addition above as a design flaw, not a naming problem, the smell of which several people has pointed out below.

Answer 1

Can you just use the plural: IFiddles?