IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Apprendre à contrôler les préconditions des méthodes d'une API Java,
Un tutoriel de François-Xavier Robin

Le , par Mickael Baron

43PARTAGES

13  0 
Bonjour,

François-Xavier Robin nous propose un tutoriel pour apprendre à contrôler les arguments des méthodes quand on élabore une interface de programmation API avec le langage Java.

Pour consulter le tutoriel : https://fxrobin.developpez.com/tutor...-methodes-api/

N'hésitez pas à laisser des commentaires à la suite.

Mickael BARON pour l'équipe Java de Developpez.com

Retrouver les meilleurs cours et tutoriels pour apprendre la programmation en Java

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de professeur shadoko
Membre chevronné https://www.developpez.com
Le 02/07/2018 à 10:20
au delà des aspects purement techniques il me semble qu'il faut beaucoup insister auprès des développeurs sur l'impact des préconditions.
Un défaut peut-être "mortel" (no way: je veux pas continuer, le code va planter) ou constituer une incitation à confirmation (à re-traiter par le code appelant).
J'ai en effet des tonnes d'exemples de refus d'exécution parce que les limites du test sont certes inquiétantes mais pas mortelles: ça arrive souvent quand on a des formulaires avec des listes: état à l'intérieur d'un pays (typique des formulaires américains), code postal ne prenant que des chiffres (impossible dans certains pays), limite d'age (oui ça m'est arrivé: j'étais employé dans une boîte ou les développeurs ne pouvaient imaginer qu'un salarié puisse être né avant 1950!), pays (que faire si vous êtes "apatride né dans la bande de Gaza sous administration égyptienne"?), espace dans le prénom ou autre caractère "bizarre" (ça m'est aussi arrivé avec un loueur de voiture. Bref si vous vous appelez 'Gaston Adhémar de Tête en Pointe' vous êtes foutu !), etc.
0  0 
Avatar de jowo
Membre chevronné https://www.developpez.com
Le 06/07/2018 à 15:54
Le troll du vendredi

ou né le 0.0.1964 si votre date réelle de naissance n'est pas connue et que l'administration suisse vous a attribué cette date de naissance sur vos documents administratifs (carte d'identité, passeport et autre...)

SVP ne pas tirer sur le
0  0 
Avatar de Mickael Baron
Responsable Java & Kotlin https://www.developpez.com
Le 06/07/2018 à 22:19
Bonjour,

Je vais demander à François-Xavier, l'auteur de l'article, de venir répondre à vos remarques.

Mickael
0  0 
Avatar de fxrobin
Membre chevronné https://www.developpez.com
Le 07/07/2018 à 15:18
Citation Envoyé par Mickael Baron Voir le message
Je vais demander à Jean-François, l'auteur de l'article, de venir répondre à vos remarques.Mickael
Mickael, tu ne devais pas être fort au Mastermind : tu en as un seul et de mal placé !

Pour répondre à professeur shadoko et jowo,

je suis assez d'accord avec vous, car il m'arrive encore d'être gêné quand il s'agit de remplir mon prénom dans certains formulaires quand un "développeur" a estimé que 10 caractères suffiraient.
C'est d'ailleurs là le problème à mon avis : ce n'est pas au développeur d'estimer cela, c'est une "précondition" métier, spécifiée par le métier !

Enfin, c'est quand même un tout petit peu hors sujet : mon article traite des préconditions d'API.
C'est à dire "backend" même si on pourrait l'étendre à certains "frontends".

Il s'agit en priorité de contrôler les arguments qui "arrivent" dans une méthode, pour éviter des valeurs nulles alors qu'elles sont nécessaires ou encore des listes vides (ou nulles) alors qu'elles sont sensées ne pas l'être.

Il faut absolument alors tester que les arguments soient "acceptables" avant de commencer tout traitement qui nécessiteraient au mieux un rollback, au pire une complexité cyclomatique (multi-imbrications de if / else) élevée pour gérer les cas d'erreurs.

Ne pas tester les arguments, revient potentiellement au code (et au bug) qui a eu pour conséquence le crash d'Ariane 5

A titre personnel, je ne teste pas partout tous les arguments, mais essentiellement sur ce que "j'offre" à l'extérieur. (D'ailleurs, c'est stipulé dans l'article).
Il ne s'agit pas de contraindre trop fortement ce qui "arrive", mais de contrôler quand même un semblant d'information correcte.

Quant à la date du 00/00/1964 en Suisse (que je ne connaissais pas) ... comment dire ... encore un système où le "métier" n'a pas su dire (ou être entendu) sur le fait qu'une date pouvait aussi être "indéterminée".

Merci de vos réactions !

François-Xavier.
0  0 
Avatar de Mickael Baron
Responsable Java & Kotlin https://www.developpez.com
Le 07/07/2018 à 15:22
Mickael, tu ne devais pas être fort au Mastermind : tu en as un seul et de mal placé !
Sincèrement désolé, il était tard et je suis perdu avec toutes les personnes avec des noms composés. Encore désolé.

Merci beaucoup pour ta réponse

Mickael
0  0 
Avatar de fxrobin
Membre chevronné https://www.developpez.com
Le 07/07/2018 à 15:34
Citation Envoyé par Mickael Baron Voir le message
Sincèrement désolé, il était tard et je suis perdu avec toutes les personnes avec des noms composés. Encore désolé.
Non mais, je te rassure, j'ai plus rigolé qu'autre chose ! Ne t'inquiète pas !
0  0