2009-01-07 8 views

Répondre

10

Si vous voulez que d'autres classes implémentent cette interface, ce serait probablement une bonne idée, ne serait-ce que pour la propreté. Quiconque regarde votre interface ne devrait pas avoir à regarder votre implémentation à chaque fois.

3

S'il n'y a qu'une seule implémentation: pourquoi l'interface?

S'il y a plus d'une implémentation: où placez-vous les autres?

+0

Pourquoi l'interface? Pour la testabilité.Pierres moqueuses :) –

+0

Convenu que même s'il n'y a qu'une seule classe concrète, elle devrait être interfacée. Cependant, j'utiliserais un fichier séparé. – ctacke

+0

Mais alors le simulacre est une autre implémentation, donc les deux implémentations devraient aller dans des fichiers séparés. –

1

Si par différents fichiers, vous voulez dire différents fichiers xxx.cs dans votre assemblage, alors normalement, en raison de mes propres pratiques, je dirais que oui - mais cela dépend des normes de la maison que vous utilisez. Si vous ne faites que de la programmation pour vous-même, je dirais que c'est une bonne pratique de codage, elle garde tout propre et facile à lire. Plus les blocs de code sont petits dans un fichier donné, plus il est facile de suivre (dans la limite du raisonnable), évidemment vous pouvez commencer à entrer dans des classes partielles où les choses peuvent commencer à devenir ridicules si vous n'y tenez pas. En règle générale, je garde mes projets dans une structure de dossiers logiques où des parties du projet peuvent être allouées dans des dossiers DAL ou BM et dans ce cas je pourrais avoir un certain nombre de dossiers nommés logiquement qui contiennent chacun un certain nombre de fichiers: une interface, une implémentation et toutes les classes auxiliaires spécifiques à celles-ci. Toutefois, tout ceci étant dit, les meilleures pratiques de votre équipe/interne devraient être adoptées si vous travaillez au sein d'une équipe de développeurs.

0

Fichiers séparés ... FTW! Vous pouvez même créer des projets/assemblages distincts en fonction de l'étendue de votre code. À tout le moins, il devrait probablement être dans un espace de noms distinct.

Le point entier d'une interface est de sorte que le code qui utilise l'interface ne se soucie pas de l'implémentation. Par conséquent, ils doivent être aussi vaguement associés que possible, ce qui ne sera pas le cas s'ils se trouvent dans le même fichier. Mais comme le note @balabaster, cela dépend des pratiques de votre équipe (bien qu'elles ne soient pas toujours des «meilleures pratiques»).

0

Oui, pour les classes on les appelle partial class, un coup d'oeil link text

+0

Sauf si je suis en train de perdre le cerveau, les classes partielles sont une chose très différente ... – ZombieSheep

+0

euh ... peut-être que je ne comprends pas la question ... Je sais que les classes partielles (qui peuvent implémenter une interface) peuvent être divisé en un ou plusieurs fichiers .cs ... – tanathos

0

Règle générale, oui. Une interface signifie qu'elle peut être implémentée par d'autres classes, qu'elle est plus propre et plus facile à gérer quand elle se trouve clairement dans des fichiers séparés. De plus, selon le niveau de séparation et d'isolation que votre application va prendre, vous voudrez même placer vos interfaces dans son propre projet. Ensuite, les projets consommants feraient référence au projet d'interface au lieu de chaque assembly qui porte des implémentations de cette interface.

0

Oui, même si on donne des contre-arguments comme s'il n'y a qu'une seule implémentation ou il/elle prévoit qu'il n'y aura qu'une seule implémentation pendant longtemps ou il/elle est le seul utilisateur/développeur, etc. plusieurs implémentations, plusieurs utilisateurs, etc, alors il est évident que vous voudriez les garder dans des fichiers séparés. Alors pourquoi devrait-on traiter différemment dans le cas d'une seule mise en œuvre?