Interfaces et versioning

Question

Je suis en train de concevoir un nouveau système et j'ai beaucoup d'interfaces qui vont grandir avec le temps avec le système. Quelle est la meilleure pratique pour nommer cette interface

ISomethingV01 
ISomethingV02 
etc 

et je fais ce

public interface ISomething{ 
     void method(); 
} 

alors je dois ajouter la méthode 2 maintenant ce que je fais?

public interface ISomethingV2:ISomething{ 
     void method2(); 
} 

ou la même façon?

Answer 1

Idéalement, vous ne devriez pas changer vos interfaces très souvent (le cas échéant). Si vous avez besoin de modifier une interface, vous devez reconsidérer son objectif et voir si le nom d'origine s'applique toujours. Si vous pensez toujours que les interfaces vont changer, et que les changements d'interfaces sont petits (ajout d'éléments) et que vous avez le contrôle de l'ensemble du code, modifiez simplement l'interface et corrigez toutes les erreurs de compilation. Si votre modification est un changement dans la façon dont l'interface doit être utilisée, vous devez créer une interface distincte (probablement avec un nom différent) pour prendre en charge ce modèle d'utilisation alternatif.

Même si vous finissez par créer ISomething, ISomething2 et ISomething3, les utilisateurs de vos interfaces auront du mal à comprendre les différences entre les interfaces. Quand devraient-ils utiliser ISomething2 et quand devraient-ils utiliser ISomething3? Ensuite, vous devez aller sur le processus de obsolète ISomething et ISomething2.

Answer 2

Le but d'une interface est de définir un modèle abstrait que le type doit implémenter.

Il serait préférable que la mise en œuvre:

public interface ISomething 

public class Something1 : ISomething 
public class Something2 : ISomething 

Vous ne gagnez rien sous la forme de réutilisabilité du code ou de la conception évolutive en créant plusieurs versions de la même interface.

Answer 3

Je ne sais pas pourquoi les gens downvote votre message. Je pense que les bonnes directives de nommage sont très important.

Si vous devez maintenir la compatibilité avec prev. version de la même interface envisager d'utiliser l'héritage. Si vous avez besoin d'introduire une nouvelle version de l'interface règle suivante envisager:

Essayez d'ajouter le suffixe significatif pour vous l'interface . S'il n'est pas possible de créer un nom concis, pensez à ajouter le numéro de version .

Answer 4

Je suis d'accord avec Garo Yeriazarian, changer d'interface est une décision sérieuse. En outre, si vous souhaitez promouvoir l'utilisation de la nouvelle version de l'interface, vous devez marquer l'ancienne version comme obsolète. Dans .NET, vous pouvez ajouter ObsoleteAttribute.

Answer 5

Je pense que vous remplacez les interfaces. Meyer et Martin nous ont dit: "Ouvert pour extension mais fermé pour modification!"

puis Cwalina (et al) a réitéré:

De Framework Design Guidelines ...

En général, les classes sont la construction préférée pour exposer des abstractions Le principal inconvénient des interfaces. est qu'ils sont beaucoup moins flexibles que classes quand il s'agit de permettre l'évolution des API.Une fois que vous expédiez une interface , l'ensemble de ses membres est fixé pour toujours. les ajouts à l'interface casseraient les types existants implémentant l'interface.

Une classe offre beaucoup plus de flexibilité. Vous pouvez ajouter des membres aux classes que ont déjà expédiées. Tant que la méthode n'est pas abstraite (à savoir, tant que vous fournissez une implémentation par défaut de la méthode), les classes existantes dérivées continuent à fonction inchangée.