Besoin de suggestions concernant la refactorisation de l'interface

Question

J'ai hérité d'un projet qui a une grosse interface maladroite déclarée (appelons-la IDataProvider). Il existe des méthodes pour tous les aspects de l'application regroupés dans le fichier. Non pas que ce soit un gros problème, mais je préfère les faire scinder en fichiers plus petits avec un nom descriptif. Refactoriser l'interface et la décomposer en plusieurs interfaces (disons IVehicleProvider, IDriverProvider etc ...) nécessitera un refactoring massif du code, car il y a beaucoup de classes qui implémentent l'interface. Je pense à deux autres façons de trier les choses: 1) Créer plusieurs fichiers pour chaque aspect de l'application et rendre l'interface partielle ou 2) Créer plusieurs interfaces comme IVehicleProvider, IDriverProvider et avoir l'interface IDataProvider héritée d'eux.

Lequel de ce qui précède préférez-vous faire et pourquoi? Ou si vous pouvez penser à une meilleure façon, s'il vous plaît dire.

Merci

Answer 1

This book suggère que les interfaces appartiennent, non pas au fournisseur, mais plutôt au client de l'interface. C'est-à-dire que vous devez les définir en fonction de leurs utilisateurs plutôt que des classes qui les implémentent. Appliqué à votre situation, les utilisateurs de IDataProvider n'utilisent (probablement) qu'un petit sous-ensemble des fonctionnalités de cette grande interface. Choisissez un de ces clients. Extrayez le sous-ensemble de fonctionnalités qu'il utilise dans une nouvelle interface et supprimez cette fonctionnalité de IDataProvider (mais si vous voulez laisser IDataProvider étendre votre nouvelle interface pour préserver le comportement existant, n'hésitez pas). Répétez jusqu'à ce que terminé - puis se débarrasser de IDataProvider.

Answer 2

Est-il exact que la plupart sinon toutes les classes qui mettent en œuvre cette interface unique grande ont beaucoup de méthodes qui soit ne font rien ou lancer des exceptions? Si ce n'est pas le cas, et vous avez de grandes classes avec beaucoup de préoccupations différentes, vous serez dans un refactoring douloureux, mais je pense que la manipulation de ce refactoring est maintenant la meilleure approche - les alternatives vous suggérez simplement de vous pousser dans différentes mauvaises situations, en différant la douleur pour un faible gain.

Une chose à peut faire est d'appliquer plusieurs interfaces à une seule classe (dans la plupart des langues) de sorte que vous pouvez simplement créer vos nouvelles interfaces et remplacer l'interface grand unique avec les multiples plus petits:

public class BigNastyClass : IBigNastyInterface 
{ 
} 

Goes à:

public class BigNastyClass : ISmallerInferface1, ISmallerInterface2 ... 
{ 
} 

Si vous ne disposez pas d'énormes classes qui mettent en œuvre l'ensemble de l'interface, j'aborder le problème d'une catégorie par classe. Pour chaque classe qui implémente cette grande interface, introduisez une nouvelle interface spécifique pour cette classe. De cette façon, il vous suffit de refactoriser votre base de code une classe à la fois.

DriverProvider par exemple passera de:

public class DriverProvider : IBigNastyInterface 
{ 
} 

Pour:

public class DriverProvider : IDriverProvider 
{ 
} 

Maintenant, vous supprimez simplement toutes les méthodes non utilisées qui ne faisaient rien au-delà de simplement satisfaire la grande interface, et fixer toutes les méthodes où DriverProvider doit être transmis.

Answer 3

Il est difficile de répondre à cette question sans aucune balise ou information nous indiquant la technologie ou les technologies dans lesquelles vous travaillez.

En supposant .NET, le refactoring initial devrait être très minime.

Les classes qui implémentent l'interface d'origine l'implémentent déjà dans son intégralité.

Une fois que vous créez les plus petites interfaces, vous venez de changer:

public class SomeProvider : IAmAHugeInterface { … } 

avec:

public class SomeProvider : IProvideA, IProvideB, IProvideC, IProvideD { … } 

... et votre code fonctionne exactement comme il l'a fait avant, tant que vous n'avez pas ajouté ou retiré des membres de ce qui était là pour commencer. À partir de là, vous pouvez réduire les classes au fur et à mesure des besoins et supprimer les méthodes et interfaces supplémentaires de la déclaration.

Answer 4

Je ferais ce dernier. Faites les interfaces individuelles, plus petites, et faites ensuite une agrégation de la «grosse» interface. Après cela, vous pouvez refactoriser la grande interface dans les consommateurs de celui-ci, selon le cas.