Разве неправильно называть класс FooFactory, если он не * всегда * создает объекты Foo?

Question

Нельзя ли называть класс FooFactory, если он не всегда создает объекты Foo?Например, если у меня есть следующий интерфейс:

public interface IFooFactory
{
    Foo Create();
}

и реализован следующим образом:

public class FooFactory : IFooFactory
{
    public IFoo Create()
    {
        return ServiceLocator.Current.GetInstance<IFoo>();
    }
}

, тогда этот класс может создать Foo в зависимости от того, как мойКонтейнер IoC настроен.Если имя 'XxxFacotry' должно быть зарезервировано для истинных фабрик, как я должен называть мой интерфейс и класс?

Очевидный ответ - IFooProvider, но я действительно хочу избегать 'XxxProvider', потому что он чрезмерно используется и поэтому слишком расплывчат.С другой стороны, IFooServiceLocator слишком конкретен.

Предложения по альтернативным именам приветствуются.

Answer 1

Вы бы назвали что-нибудь фабрикой печенья, если бы она иногда делала торт?

Answer 2

Ваш класс предоставляет и IFilter, что может повлечь или не повлечь за собой его создание. Я не вижу, как FilterProvider слишком расплывчато.

Если вам не нравится, как насчет FilterSource?

Честно говоря, я не думаю, что было бы так плохо называть это FilterFactory; Я имею в виду, кого это волнует, как это реализовано? Если кто-то вызывает ваш Create метод, скорее всего, он кеширует результат, что делает его довольно спорным, знают ли они, что Create на самом деле не создает экземпляр нового объекта с нуля.

В любом случае, правильная вещь - это документировать фактическую функциональность вашего класса, включая любые детали, которые будут важны для тех, кто его использует (и пропускает те детали, которые на самом деле не имеют значения или не важны).

Answer 3

Пока что кажется 50/50. Поэтому я принимаю ответ, который подразумевает «Да; неправильно называть что-либо как FooFactory, если оно не всегда создает новые объекты Foo ', потому что именно в этом мое собственное предпочтение.