Conception d'une api

Bonjour,

Je suis actuellement en train de concevoir une api, c'est a dire que tout ce que je fait est principalement destine a etre utilise par d'autres.

Il m'est deja arrive de trouver certaines api lourde a utiliser, mais sans jamais voir en general d'ou vient le probleme!

J'ai maintenant un probleme bien particulier:
On hesite entre regrouper un paquet de fonctions sous une seule grosse fonction mais qui serait du coup lourde en nombre d'arguments et moins claire dans ses fonctionnalites ou bien garder plusieurs fonctions dont le nommage serait plus clair sur leur fonctionnalite, solution qui pourra sembler plus fouilli...

Qu'est-ce qui est a priori le plus simple/agreable a utiliser?

Bonjour,

Citation:

---

Envoyé par Babaôrom

Qu'est-ce qui est a priori le plus simple/agreable a utiliser?

---

plusieurs fonctions, sauf bien-sur pour les variations de détail

sinon, je pense qu'un des pièges à éviter lorsqu'on fait une API est de mettre trop de choses, et donc y compris des fonctions que l'utilisateur peut faire lui même en utilisant des briques de base de l'API. Au final l'utilisateur est perdu s'il y a trop de possibilités. Cependant mettre le 'bon' niveau de fonctionalité n'est pas aisé, sans compter que tout le monde ne sera pas d'accord avec ce qu'est le 'bon' niveau :aie:

Le problème c'est donc posé pour l'API des plug-outs de Bouml, et j'ai décidé de mettre juste les opérations de base, pas de fioritures. Cela est viable (j'espère ;) ) car les utilisateurs peuvent étendre cette API à leur guise pour ajouter des fonctionalités de plus 'haut niveau', l'API est présentée sous forme de classes avec un mécanisme d'héritage ou une classe sur deux est 'système' (non modifiable) et l'autre 'utilisateur' (modifiable).

Merci bien pour ta reponse, c'est egalement l'avis que j'avais, mais de temps en temps une petite confirmation exterieure ne fait pas de mal!