Is it wrong to call a class a FooFactory if it doesn't *always* create Foo objects?

Is it wrong to call a class a FooFactory if it doesn't always create Foo objects? For example if I have the following interface:

public interface IFooFactory
{
    Foo Create();
}

and implement it as follows:

public class FooFactory : IFooFactory
{
    public IFoo Create()
    {
        retur开发者_Python百科n ServiceLocator.Current.GetInstance<IFoo>();
    }
}

then this class might create a Foo depending upon how my IoC container is configured. If the 'XxxFacotry' name should be reserved for true factories, what should I call my interface and class?

The obvious answer is IFooProvider, but I really want avoid 'XxxProvider' because it's overused and therefore too vague. On the other hand, IFooServiceLocator is far too specific.

Alternative naming suggestions greatly appreciated.

---

Would you call something a cookie factory if it sometimes made cake?

---

Your class provides an IFilter, which may or may not entail creating one. I fail to see how FilterProvider is too vague.

If you don't like it, what about FilterSource?

Honestly, though, I don't think it'd be so bad to call it FilterFactory; I mean, who cares that much how it's implemented? If someone calls your Create method, chances are they're caching the result, which makes it pretty moot whether or not they know that Create doesn't actually instantiate a new object from scratch.

Either way, the right thing to do is document your class's actual functionality, including whatever details will be relevant to those utilizing it (and omitting those details which are, in fact, irrelevant or unimportant).

---

So far, it seems to be 50/50. So the answer I'm accepting is the one that implies 'Yes; it is wrong to name something as a FooFactory if it doesn't always create new Foo objects' because that's where my own preference lies.