Je fais des travaux de conception de l'API à l'heure actuelle, impliquant la spécification d'un certain nombre d'interfaces comme des abstractions qui seront ultérieurement mises en œuvre par diverses classes en béton.
Comme cela se produit, j'utilise Java, mais je pense que la question est pertinente pour toute langue prenant en charge un concept d'interface similaire.
J'ai remarqué qu'il y a souvent une option entre:
Quels sont les avantages / inconvénients de chaque approche?
7 Réponses :
Je ne préconiserais pas une interface avec trop de méthodes, comme je ne le ferais pas pour une classe. Le programmeur qui doit utiliser ces interfaces ou les classes dérivées aurait du mal à comprendre comment ils se rapportent; En outre, essayant de se rappeler ce qu'ils sont et quand on doit utiliser, c'est comme jongler trop de balles.
Pour moi, en général, plus de 1000 lignes dans un module sont trop nombreuses; plus de 100 lignes dans une méthode aussi; Plus de 15 méthodes ou plus dans une classe ou une interface également. Bien sûr, il peut y avoir des exceptions, mais j'essaie de les éviter.
Je définirais les interfaces que vous avez avant de penser quelles méthodes les entrent. Considérez quelles sont les «comportements atomiques» pour chaque entité abstraite de votre système et rendent chaque entité une interface, composant avec héritage si nécessaire. Puis décidez les méthodes - après cela, il n'y aurait probablement pas beaucoup dans chaque interface.
+1 @fabio vos numéros sont bons. J'aurais une autre règle de numéro de pouce. J'évite les fonctions prenant plus de 4/5 paramètres. Et sur les 100 lignes méthodes ... dans l'acte ma limite est ma taille d'écran: Si je ne peux pas lire toute la fonction pour commencer à terminer dans un tout, il est trop long, ma limite est donc de 50 lignes de code par fonction: -)
Je suis totalement d'accord, y compris la taille de la méthode - une qui convient à l'écran est idéale. Dans mon cas particulier, j'ai dû détendre cette règle un peu parce que je voulais avoir le même standard pour toutes les langues que j'utilise (Java, C, C ++, C #) et lorsque la programmation en C / C ++ pour Windows est plus difficile à faire de petites méthodes. Parfois - avec toutes ces énormes fonctions de l'API Win32 et des structures qui ressemblent à des formes IRS.
Le pro de fractionnement de l'interface est que vous pouvez diviser les méthodes en groupes de responsabilités qui ont du sens à être ensemble. Le con est l'interface de votre interface est maintenant divisée en un tas de plus petits qu'une classe peut être mise en œuvre.
Je recommanderais de diviser l'interface où elle aide la lisibilité et non plus loin. Si vous avez une classe qui met en œuvre 10 interfaces, ces interfaces doivent être combinées en une ou éventuellement la classe prend beaucoup de responsabilité et il doit vraiment être deux classes ou plus.
Faire de plusieurs interfaces contenant chacun un sous-ensemble de la gamme complète des méthodes
Cette approche aurait tendance à mieux fonctionner avec le principe de conception de " préférer la composition à l'héritage ", parce que des classes séparées pourraient appliquer une (ou quelques-unes) des interfaces.
En termes d'anti-motifs, je dirais que trop d'interfaces peuvent conduire au soi-disant problème YO-YO-problème:
http://fr.wikipedia.org/wiki/yo-yo_problem < / p>
et tout mettre dans une seule interface peut créer l'objet de Dieu:
http://en.wikipedia.org/wiki/god_Object
Vous devriez trouver votre place quelque part entre :)
bonne chance!
Je n'ai pas de bonne réponse à votre question. La conception de l'API est un peu un art. Si vous êtes au milieu d'un grand effort de conception, je vous recommande de vous procurer une copie de Conception pratique API Par Jaroslav Tulach de Netbeans Fame.
Je pense qu'il recommanderait de trop de méthodes, dont certaines pourraient simplement être des méthodes d'assistance. Vous devez exposer le minimum nécessaire pour travailler avec l'API. Le moins verbeux, mieux c'est.
Le nombre de méthodes dans une interface doit être entraîné uniquement par son utilisation connue (ou attendue). Si les appelants utilisent généralement trois membres différents (mais qui se chevauchent) d'une interface de six membres d'une interface, alors six c'est!
Un grand nombre de méthodes indiquent souvent une cohésion médiocre et une bonne conception d'objet doit placer une limite naturelle sur ce nombre quand même. Mais vous ne devriez jamais diviser une interface uniquement pour réduire le nombre de méthodes qu'il contient.
Un problème non mentionné: les interfaces qui mettent des éléments dans une collection doivent être séparées de celles qui prennent des articles; Une interface combinée doit hériter des deux. Séparer les interfaces de cette manière permet de la covariance et de la contrevenance. Par exemple, une religieusebunch (de ToyoPrius) peut être transmise en toute sécurité à une routine qui s'attend à une machine lisible (de la voiture) [car un objet qui donne des cas de ToyoPrius va donc donner des cas de voiture] et une voiture écrite (de voiture ) Peut être transmis en toute sécurité à une routine qui s'attend à une wriancequeur (de Hondacivic) [puisqu'un objet pouvant accepter une voiture sera par définition accepter un Hondacivic].
Je ne sais pas si ce type de covariance et ce type de covariance et de cravariance signifient quoi que ce soit en Java, mais comme la question a été marquée par une langue-agnostique, la question doit être envisagée par quiconque codant pour les plateformes qui soutiennent la covariance et la contrevenance (par exemple)
Nice principe - +1 pour m'aider directement avec l'une des décisions de conception de l'API, je suis au milieu de!
Avez-vous vu l'article de Bob Martin sur le principe de ségrégation de l'interface? Objectmentor.com/resources/articles/isp.pdf
@Nathan - article très intéressant - merci!
@Nathanhughes Le lien n'est plus disponible.