Détectable, car justement, l'utilisateur n'aura aucun moyen de me balancer un « nonInt » en paramètre. Ou s'il le fait, le compilo le rappelera à l'ordre.
open(string)
Détectable aussi, via test unitaire.
Si tu lui passes un nom d'oiseau, typiquement ça doit te balancer un « No such file or directory »
On pourrait multiplier les exemples avec tout ce qui touche à l'interface utilisateur
Dans « utilisateur », il y a « utilisateur final », pour qui effectivement, tu dois survérifier tout ce qu'il est susceptible de te balancer, mais aussi « autre développeur » (aussi bien de ta propre équipe, mais peut-être aussi d'une autre équipe qui utilise ton API).
Le cas du canard à la con, c'est typiquement le cas d'un co-dev Python qui a fait son propre objet en mimant ce qu'il a pu déjà voir ailleurs, mais en omettant tout ce qui était du domaine des API internes, pourtant nécessaires au bon fonctionnement de l'application.
Dans le code de mon paste, c'est typiquement dès les 1ères lignes que le développeur de l'API aurait du refuser le canard boiteux (« f.addDuck(aFakeDuckWithoutFeathers) »). Sauf que pour faire ça, il aurait fallu avoir connaissance de toutes les méthodes que l'application est potentiellement en droit d'appeler sur l'objet en question. Littéralement impossible… sauf à réimplémenter du typage statique !
[^] # Re: Le titre est trop long
Posté par Aeris (site web personnel) . En réponse au journal Typage statique versus typage dynamique. Évalué à 4.
Détectable, car justement, l'utilisateur n'aura aucun moyen de me balancer un « nonInt » en paramètre. Ou s'il le fait, le compilo le rappelera à l'ordre.
Détectable aussi, via test unitaire.
Si tu lui passes un nom d'oiseau, typiquement ça doit te balancer un « No such file or directory »
Dans « utilisateur », il y a « utilisateur final », pour qui effectivement, tu dois survérifier tout ce qu'il est susceptible de te balancer, mais aussi « autre développeur » (aussi bien de ta propre équipe, mais peut-être aussi d'une autre équipe qui utilise ton API).
Le cas du canard à la con, c'est typiquement le cas d'un co-dev Python qui a fait son propre objet en mimant ce qu'il a pu déjà voir ailleurs, mais en omettant tout ce qui était du domaine des API internes, pourtant nécessaires au bon fonctionnement de l'application.
Dans le code de mon paste, c'est typiquement dès les 1ères lignes que le développeur de l'API aurait du refuser le canard boiteux (« f.addDuck(aFakeDuckWithoutFeathers) »). Sauf que pour faire ça, il aurait fallu avoir connaissance de toutes les méthodes que l'application est potentiellement en droit d'appeler sur l'objet en question. Littéralement impossible… sauf à réimplémenter du typage statique !