Quelle option de conception est préférable d'utiliser pour coder un framework?

Question

Je suis en train de coder un framework (en Java, mais question est générique) dans lequel je vais fournir un ensemble d'interfaces à implémenter pour les clients. Les fonctions du framework vont dépendre de la façon dont les classes d’implémentation seront construites, c’est-à-dire qu’elles dépendent de ces implémentations pour fournir d’autres instances d’interfaces.

Par exemple, je pourrais avoir:

Interface IContribution {
   public IMyStuff getMyStuff();
   public IHelper getHelper();
}

Interface IMyStuff {
     public void doSomeMethod(IHelper helper);
}

Comment puis-je m'assurer que ces instances de IMyStuff et IHelper sont disponibles?

Une méthode consisterait à créer les méthodes "getter" dans l'interface et à vérifier minutieusement les objets nuls renvoyés.

Une autre option serait de créer des classes abstraites qui implémentent une fabrique qui appelle (en utilisant des modèles de stratégie) les méthodes d'interface à implémenter. Mais cela défie le fait que j'ai l'interface en premier lieu. Les clients doivent ensuite utiliser la classe abstraite. Mais ils pourraient contourner ce problème en utilisant l'interface à la place de la classe abstraite. Par conséquent, je ne devrais pas fournir l'interface mais seulement la classe abstraite ...

Alors, quelles sont vos idées à ce sujet, quelle est une approche pragmatique à cet égard?

Answer 1

  

Comment puis-je m'assurer que ces instances de IMyStuff et IHelper sont disponibles?

Si les clients sont responsables de la mise en oeuvre des interfaces et des classes elles-mêmes, je dirais qu'il leur incombe de s'assurer que ces instances sont disponibles - je ne me soucierais pas de l'insérer dans mon propre code.

Answer 2

Pour créer un bon cadre, vous devez simultanément créer une application autour de celui-ci. De cette façon, vous saurez et comprendrez la douleur que vos clients subiront AVANT que la situation ne leur soit imposée.

En d’autres termes, commencez par: Comment mes clients travailleraient-ils avec cette application? Comment ont-ils besoin de travailler avec?

Vous réaliserez immédiatement que la méthode la plus simple, de leur point de vue, sera la meilleure.

Answer 3

Vous ne pouvez pas vous en assurer uniquement avec les interfaces, pas de comportement.

Je suis d'accord avec la philosophie de la programmation défensive du Framework, j'aide les développeurs à éviter les erreurs.

Vous pouvez fournir un objet d'usine:

public class MyPoliceman {
    public IContribution makeContributor( IMyStuff stuffer, IHelper helper)
                    throws BadAssociatesException {

     // check validity of stuffer and helper here, throw exceptions if null
    }
}

Nous pourrons au moins vérifier les valeurs nulles, etc.

Avec un peu de réflexion, il est généralement possible d’aider les développeurs. Dans certains cas, le mieux que vous puissiez faire est de piéger les erreurs et de les signaler avec précision. Par exemple ici, un IHelper parfaitement fin pourrait être transmis à votre usine, mais des actions ultérieures sur la classe pourraient la rendre incapable. (par exemple, Image c’était un fichier et un effet secondaire a ensuite fermé le fichier.) Il ne vous reste plus alors qu’à intercepter la condition d’erreur résultante, à enregistrer une erreur quelque part et à (probablement) renvoyer une exception. Alors au moins le développeur a un indice sur ce qu'il faut corriger.