Modularité: Utilisation d'interfaces ou non?

Question

Depuis quelques années, le bon sens semble dicter qu'il est préférable de programmer contre les interfaces plutôt que contre les mises en œuvre. En effet, cela semble pour le code de haut niveau logique, par exemple si j'ai un solveur complexe dans mon application, il semble préférable d'avoir quelque chose comme ceci:

ISolver *solver = solverFactory.getSolver();
solver->solve(inputdata);

Au lieu de

Solver solver;
solver.solve(inputdata);

Dans le premier code, il est également plus facile de se moquer du solveur, et donc, pour test unitaire.

Mais ma question est: à quel niveau ne pas plus de sens à utiliser l'interface. Par exemple. si j'ai une classe ComplexNumber (ou la classe String, ou autre) dans ma demande, puis en écrivant ceci:

IComplexNumber *complexNumber = complexNumberFactory.create(1,2);   // 1+2i

Il semble beaucoup plus complexe (en particulier en ce qui concerne la performance) que l'écriture:

ComplexNumber complexNumber(1,2);   // 1+2i

Alors, quels sont les éléments importants pour décider si quelque chose doit être mis derrière une interface et quand il ne doit pas être mis derrière une interface?

Answer 1

raisons de passer à une interface sont quand il rend les choses plus simples ou réduit le couplage. (Voilà ce que l'interface est pour).

Les raisons de se éloigner d'une interface sont si cela rend les choses plus compliquées ou tue la performance (mais profil pour être sûr). Je dirais que votre classe IComplexNumber fait en fait le serait plus complexe ... USEFULL classe heirarchy à moins que vous l'introduction d'un MockComplexNumber, mais je doute une telle classe et il faudra probablement faire rendre les choses plus lentement, mais je mesure .

Mais ne pensez pas que vous devez faire tout d'une façon, ou que vos décisions sont fixées dans la pierre. Il est assez facile de convertir en / à l'aide d'une interface.

Answer 2

Si vous divisez vos classes en « service » et les classes « valeur », en fonction des rôles qu'ils jouent, alors la réponse est simple. Utilisez uniquement des interfaces sur les classes de service. Dans votre question, « solveur » est un service et « nombre complexe » est une valeur.

classes de valeur doivent être faciles à créer à l'aide de nouveaux () parce qu'ils acceptent uniquement les types de base et d'autres classes de valeur dans le constructeur. classes de valeur ne sont pas utiles pour se moquer parce que vous pouvez utiliser la chose réelle.

Il peut être utile à des classes de service simulacres et vous pouvez plusieurs implémentations. Votre solverFactory pourrait revenir un naiveSolver, un lookupSolver, un geneticSolver, un mockSolver etc. Voici une interface est uesful.

Answer 3

Avec C ++, il n'a pas d'importance, comme C ++ a l'héritage multiple et donc une interface est une classe abstraite que vous pouvez ajouter à Implémentation. Là où j'ai trouvé des interfaces le plus utilisé est Java et C # qui ont l'héritage unique et si vous wan une classe pour mettre en œuvre plusieurs choses que l'on peut être une classe abstraite les autres interfaces doivent être