2

Est-ce une erreur d'appeler une classe FooFactory si ce n'est pas le cas toujours créer des objets Foo? Par exemple, si je l'interface suivante:Est-ce une erreur d'appeler une classe FooFactory si elle ne crée pas * toujours * des objets Foo?

public interface IFooFactory 
{ 
    Foo Create(); 
} 

et mettent en place comme suit:

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

alors cette classe pourrait créer un Foo en fonction de la façon dont mon conteneur IoC est configuré. Si le nom 'XxxFacotry' doit être réservé aux vraies usines, que dois-je appeler mon interface et ma classe? La réponse évidente est IFooProvider, mais je veux vraiment éviter 'XxxProvider' car il est trop utilisé et donc trop vague. D'un autre côté, IFooServiceLocator est beaucoup trop spécifique.

D'autres suggestions d'appellation ont été grandement appréciées.

+1

Eh bien qu'est-ce que vous attendez d'un CarFactory? Droite. Ils produisent la bière que j'ai en ce moment. –

+1

Ouais je ne pense pas que ce devrait être une "usine" si elle ne crée pas toujours une nouvelle instance puisque c'est ce que son nom implique. – TheCloudlessSky

+2

Personnellement, je préférerais Provider à Factory si les instances peuvent être réutilisées, mais je pense que c'est subjectif. L'important est d'utiliser les termes de manière cohérente dans votre base de code. –

Répondre

3

Est-ce que vous appelleriez quelque chose une usine de biscuits si elle faisait parfois du gâteau?

+9

Dépend de [si la TVA est payante] (http://en.wikipedia.org/wiki/Jaffa_cakes#Cake_or_biscuit.3F). –

+0

Ou mieux: Est-ce que vous appelez un lieu une usine de biscuits si vous vous êtes présenté et ils avaient seulement quelques biscuits et ils étaient comme, "Partager, tout le monde!" –

+0

Succinctement mis! –

3

Votre classe fournit et IFilter, ce qui peut ou non entraîner sa création. Je ne vois pas comment FilterProvider est trop vague.

Si vous ne l'aimez pas, qu'en est-il de FilterSource?

Honnêtement, cependant, je ne pense pas que ce serait si mauvais de l'appeler FilterFactory; Je veux dire, qui se soucie autant de comment ça se passe? Si quelqu'un appelle votre méthode Create, il y a de fortes chances pour qu'ils mettent en cache le résultat, ce qui fait qu'il est plutôt inutile de savoir si Create n'instaure pas un nouvel objet à partir de zéro. De toute façon, la bonne chose à faire est de documenter la fonctionnalité réelle de votre classe, y compris les détails qui seront pertinents pour ceux qui l'utilisent (et en omettant les détails qui sont, en fait, sans importance ou sans importance).

+1

Je ne suis pas sûr que documenter la classe concrète aiderait que les consommateurs utiliseront l'interface pour accéder à l'usine. Par conséquent, ils doivent s'appuyer sur le contrat impliqué par le nom et non la documentation de la classe concrète. Je reconnais cependant que l'IFilterProvider peut être acceptable et que mon objection à cet égard est purement subjective. –

+0

@Damian: Picky difficile! Tu as raison; J'aurais dû dire "type" plutôt que "classe"; Mon point était que vous devriez documenter tout ce qui doit être documenté. Dans le cas de 'IFilterFactory', par exemple, que d'autres interprètent ou non la partie -Factory pour indiquer qu'une implémentation crée une nouvelle instance, vous pouvez mettre dans la documentation:" IFilterFactory "fournit une instance d'un Implémentation de 'IFilter' via la méthode' Create', ce qui n'est pas garanti pour créer un nouvel objet. " Mais alors avec cette définition, il semble vraiment que «IFilterProvider» pourrait avoir plus de sens. –

0

Jusqu'à présent, il semble être 50/50. Donc la réponse que j'accepte est celle qui implique 'Oui; est tort de nommer quelque chose comme un FooFactory si ce n'est pas toujours créer de nouveaux objets Foo 'parce que c'est là ma préférence.

+0

Je pense que vous avez pris une sage décision là-bas – Proclyon