Une différence de style : IDictionary vs Dictionary

Question

J'ai un ami qui se lance dans le développement .NET après avoir développé en Java pendant des années et, après avoir examiné certains de ses codes, j'ai remarqué qu'il fait assez souvent ce qui suit :

IDictionary<string, MyClass> dictionary = new Dictionary<string, MyClass>();

Il déclare que le dictionnaire est l'interface plutôt que la classe. Typiquement, je ferais ce qui suit :

Dictionary<string, MyClass> dictionary = new Dictionary<string, MyClass>();

Je n'utiliserais l'interface IDictionary que lorsqu'elle est nécessaire (par exemple, pour passer le dictionnaire à une méthode qui accepte une interface IDictionary).

Ma question est la suivante : sa façon de faire a-t-elle des mérites ? S'agit-il d'une pratique courante en Java ?

Answer 1

Si IDictionary est un type "plus générique" que Dictionary, il est logique d'utiliser le type le plus générique dans la déclaration des variables. De cette façon, vous n'avez pas à vous soucier autant de la classe d'implémentation affectée à la variable et vous pouvez facilement changer le type à l'avenir sans avoir à modifier une grande partie du code suivant. Par exemple, en Java, il est souvent considéré comme préférable de faire

List<Integer> intList=new LinkedList<Integer>();

qu'il ne l'est de faire

LinkedList<Integer> intList=new LinkedList<Integer>();

De cette façon, je suis sûr que tout le code suivant traite la liste comme une liste et non comme une liste chaînée, ce qui facilitera à l'avenir le remplacement de la liste chaînée par un vecteur ou toute autre classe qui implémente la liste. Je dirais que ceci est commun à Java et à la bonne programmation en général.

Answer 2

Cette pratique ne se limite pas à Java.

Il est souvent utilisé dans .NET également lorsque vous voulez découpler l'instance de l'objet de la classe que vous utilisez. Si vous utilisez l'interface plutôt que la classe, vous pouvez changer le type de support chaque fois que nécessaire sans casser le reste de votre code.

Vous verrez également que cette pratique est très utilisée pour traiter les conteneurs IoC et l'instanciation à l'aide du modèle Factory.

Answer 3

Votre ami suit le principe très utile :

"S'abstraire des détails de mise en œuvre"

Answer 4

Vous devez toujours essayer de programmer en fonction de l'interface plutôt que de la classe concrète.

En Java ou tout autre langage de programmation orienté objet.

Dans le monde .NET, il est courant d'utiliser un I pour indiquer que c'est une interface que vous utilisez. Je pense que c'est plus courant parce qu'en C# ils n'ont pas de implements y extends pour faire référence à l'héritage des classes et des interfaces.

Je pense que le petit-lait ferait l'affaire

 class MyClass:ISome,Other,IMore 
 { 
 }

Et vous pouvez dire ISome un IMore sont des interfaces tandis que Other est une classe

En Java, il n'y a pas besoin d'une telle chose.

 class MyClass extends Other implements Some, More {
 }

Le concept reste valable, vous devez essayer de coder en fonction de l'interface.

Answer 5

D'après ce que j'ai vu, les développeurs Java ont tendance à utiliser l'abstraction (et les modèles de conception) plus souvent que les développeurs .NET. Ceci semble en être un autre exemple : pourquoi déclarer la classe concrète alors qu'il ne travaillera essentiellement qu'avec les membres de l'interface ?