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?

Answer 2

I would say that the name you choose should be dependent on what you are trying to achieve. In the code example I'd say what you are doing is setting up a rating, so I'd probably call it IFiddleRating

As a general answer I'd say "it depends" :) I find its a good idea to name stuff after what its trying to do, not what it "is"

Answer 3

I agree with you in that naming a class, interface or abstract class is really difficult to get right. Some possible names that I have used before which you might like are:

• xxxAssistant
• Compositexxx
• xxxCoordinator
• xxxGroup

Answer 4

As Pop said: "If you can't name it, then I smell something fishy in the design."

maybe rethink your design.

IFiddles : IDictionary<SomeType, IFiddle>
{
}

Update: If you want it to be readonly create an interface for that yourself:

IReadOnlyDictionary<TKey,TValue>
{
     TValue this[TKey] { get; }
     int Count { get; }
     ...
}

Your life can still as easy as before.

Answer 5

I think this is really a problem of personal preference, so I fired up a thesaurus and looked for synonyms of "Family" (which could be ok in itself).

kin, classification, genre, group, kind, subdivision, association, affiliation, alliance, clan, clique, club, coalition, combination, combo, confederacy, confederation, congress, cooperative, family, federation, fellowship, fraternity, gang, guild, league, mob, order, organization, ring, society, sodality, sorority, syndicate, tie-in, tie-up, tribe, troops, troupe, zoo

I dropped a few which have a specific technical meaning (like union, ring, pool)... pick what you like best.