J'ai une classe d'usine, Toute la mise en œuvre réside dans l'espace de noms suivant
skim.ssms.addin.activefileeexplorer.loader
Mais ce que je me demande est, quel espace de noms Quels seront les avantages et inconvénients de la mise en place de la méthode d'usine dans documentationLoaderFactory , qui renvoie simplement une instance qui implémente une interface, IdocumentLoader . .
documentaireLoaderFactory appartient-il?
J'ai placé la classe d'usine sous le *. Loader Espace de noms pour le moment, mais il est utilisé à partir d'un contrôle de l'utilisateur ( ActiveFileWindow ) de l'espace de noms parent, SKIM .Ssms.addin.activefileExplorer comme indiqué ci-dessous.
*. chargeur ou son espace de noms parent? Je voudrais prendre une décision en fonction de avantages / inc.
Voici la mise en page de mon projet
3 Réponses :
Je dirais que je le laisserais dans le **. Loader * Espace de noms telle qu'elle facilitera la recherche lorsque vous travaillez avec vos implémentations IdocumentLoader .
Pour autant que je sache, il ne faut généralement pas appeler / instancier un objet / méthode d'espace de noms d'enfants. Mais si je devais déplacer l'usine vers l'espace de noms des parents, la méthode d'usine ne serait-elle pas la seule à accéder aux classes de l'espace de noms d'enfant?
Pourquoi dirais-tu ça. Je ne vois pas une raison pour laquelle un objet ne peut pas appeler / instancier et méthode / objet d'un espace de noms d'enfant. Cela dépend vraiment de la façon dont vous voulez que votre API ressemble de l'extérieur.
Je dirais de son mieux pour colomber vos usines avec le (s) type (s) qu'ils créent. Une usine est un fournisseur de quelque chose et devrait être associé et proximant à ce qu'il fournit. Si vous suivez les règles de la cohésion, vous arriveriez à la même conclusion. Les choses liées doivent être rapprochées pour maintenir une API cohérente.
@jrista: J'ai décidé de quitter la classe d'usine dans * Espace de noms de chargeuse. Avoir la méthode d'usine dans l'espace de noms des parents sembler polluer la structure du projet.
Je pense que c'est le bon endroit. :) Si vous décidez déjà de tirer l'espace de nom de chargeur dans son propre montage, vous ne rencontrerez pas de problèmes avec les références manquantes d'usine ou quoi que ce soit comme ça.
Parce que le code qui utilise vos besoins en usine n'a absolument aucune connaissance de la mise en œuvre dans le modèle d'usine abstraite, je mets habituellement l'interface et l'usine (plus toutes les informations de type) dans la racine, puis les implémentations dans leurs propres dossiers ( ou dossier s'il y en a peu).
Donc, dans votre cas, j'ai quelque chose comme: J'ai supposé que le chargeur de documents est une classe de base abstraite qui hérite de votre interface En raison de son nom, mais vous obtenez l'idée. Je ne sais pas ce que votre autre classe "arbreviewimageindex" est pour mais que vous pourriez le mettre à l'un ou l'autre endroit, complètement différent si c'est approprié. Ceci garde votre code agréable et cohérent, ne nécessite pas votre mise en œuvre. classe à connaître sur l'espace de nom de chargeur \ implémenté et permet à votre arborescence de document pour être plus facile à lire.
@Odd: merci, impair. Oui, le chargeur de documents est une classe abstraite . Et créer un autre espace de noms pour la mise en œuvre est une approche que je n'ai pas pensé à
@ODD: L'abstraitement en introduisant un autre espace de noms semble solide mais ayant une trop grande partie d'un espace de noms dans mon cas ne semble pas valoir la peine de faire la peine de faire face à mon cas particulier.
C'est bien, ça ne convient pas à tout le monde. Personnellement, je n'aime pas garder trop de classes dans un espace de noms unique / répertoire car il cloque mon code et où je peux séparer logiquement, je le fais.