Motivation pour les API surchargées?

Question

Il semble qu'il y ait une quantité décente d'aversion par ici pour les APIs horriblement surdimensionnées qui sont conçues pour être infiniment flexibles et ne simplifient donc pas les choses simples. Néanmoins, il semble qu'il n'y ait pas de pénurie d'API qui vous oblige à utiliser 8 classes différentes et à écrire 20 lignes de passe-partout simplement pour accomplir des tâches simples et courantes. Je ne mentionnerai pas les noms parce que ce n'est pas censé être une guerre pour savoir si des API spécifiques sont surexploitées.

Quelle est, selon vous, la cause première de ces API surdimensionnées? Que pensez-vous qu'il doit se passer pour empêcher les concepteurs d'API de créer de telles monstruosités?

Edit: À mon humble avis, même la création de code réutilisable est vraiment une bonne réponse, car si l'API est ridiculement difficile à utiliser et nécessite des tonnes et des tas de plats, les avantages de la réutilisation deviennent discutables.

Answer 1

Je ne pense pas que rien puisse empêcher les gens de trop réfléchir. C'est inhérent à la résolution de problèmes. Des méthodologies comme XP tentent de le décourager, mais quand tout se résume, tout le monde pense "Mais si je rends cela plus générique, alors je peux le réutiliser dans tel ou tel"

Answer 2

"L'optimisation prématurée est la racine de tous les maux."
--Don Knuth

Même si, il est très, très tentant parce que les programmeurs instinctivement comme l'efficacité et l'intelligence.

Answer 3

Deuxième effet système?

Answer 4

La racine de tout mal est que les développeurs ne sont pas a) intelligent/expérimenté et b) assez adéquat.

Answer 5

Je crois que c'est souvent une conséquence de la soi-disant Second System Effect. Les concepteurs tirent les leçons de leur première version du design «version 1» et rendent la nouvelle version tellement plus flexible qu'elle devient trop complexe et difficile à comprendre.

Le livre de Fred Brooks The Mythical Man-Month a introduit ce terme et en parle en détail.

Answer 6

Je ne sais pas s'il s'agit d'un cas de sur-ingénierie ou d'abstraction insuffisante. L'API de Windows en est un parfait exemple.

Il était une fois, j'ai passé beaucoup de temps à écrire un moteur d'impression et de prévisualisation. Je devais décoder les fenêtres api appels nécessaires pour afficher les choses sur l'écran et la sortie vers une imprimante. En créant l'abstraction api j'ai essayé de penser en termes de ce que le développeur essaye d'accomplir ... par exemple: "Je veux dessiner une ligne rouge large de 1point de coordonnées (1, 1) à (8, 1) - exprimé en pouces. " L'équivalent de Windows pour ce code implique beaucoup, beaucoup de lignes irritantes de code ... créer un pinceau, le sélectionner dans un contexte de périphérique, définir le point de départ, gérer les conversions de pouces en pixels, dessiner à un point final , etc. mon api abrégé est un appel unique: dpLine (documentHandle, x1, y1, x2, y2, largeur, couleur); // où x1, x2, y1, y2 sont exprimés en pouces

Dans ce cas, je pense que l'API gdi de Windows est trop bas niveau. Je suis sûr qu'il y a de bonnes raisons pour les choses qu'ils ont faites et n'ont tout simplement pas le temps et l'énergie pour faire une interface appropriée pour les programmeurs qui sont susceptibles de l'utiliser. La raison de la monstruosité est probablement juste des délais.L'API est techniquement précise; cela permet à un programmeur de faire ce dont il a besoin. C'est assez bon pour l'expédier. Mais, il est si bas niveau que les abstractions de tiers sont nécessaires pour le rendre utilisable. IMO, vous pouvez faire un argument pour un système d'exploitation pour fournir une api compliquée de bas niveau comme celle-ci, mais un outil tiers ne devrait pas être si compliqué.

-Don

Answer 7

Je pense que Python a souffert de Second Effect système. Dans la version 2.x, deux types de classes et de sémantiques différentes existent.

Espérons que Python 3.0 résout la plupart de ces problèmes.