Nous utilisons tous des fichiers Clients, Fournisseurs, Produits ou autres,
dont les clés sont des nombres entiers banalisés (souvent attribués
automatiquement par notre base de données).
Dans les programmes, ces clés sont déclarées en Integer.
En fait, ce n'est pas terrible ! Cela permet d'écrire des aberrations du
genre
NumProduit = NumClient * NumFournisseur +3
La question est donc : comment est-il possible de définir des types
spécifiques pour les numéros de client, etc. de sorte que tout mélange
provoque une erreur à la compilation ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Patrice
Integer n'est pas une classe mais cela n'a aucune importance dans la discussion...
Il serait peut-être possible d'utiliser des types spécifiques pour éviter toute opération mais bien voir si le jeu en vaut la chandelle. L'exemple donné ne me parait pas très réaliste (en gros, le développeur fait vraiment n'importe quoi).
Concrètement NumProduit serait sans doute en lecture seule en lecture seule (car attribution automatique par la bd) et le code ne compilerait pas à cause de cela (et non pas à cause de l'opération).
Une autre solution serait d'utiliser un guid (mais si je pousse le raisonnement à l'extrème, un développeur pourrait convertir le guid en octets et en faire n'importe quoi...)
Pour l'instant je pense que ce point est exagéré et que le jeu est loin d'en valoir la chandelle. Il y a sans doute bien d'autres points plus importants à traiter... --
Patrice
"Gilbert Tordeur" a écrit dans le message de groupe de discussion :
Bonjour.
Nous utilisons tous des fichiers Clients, Fournisseurs, Produits ou autres, dont les clés sont des nombres entiers banalisés (souvent attribués automatiquement par notre base de données).
Dans les programmes, ces clés sont déclarées en Integer.
En fait, ce n'est pas terrible ! Cela permet d'écrire des aberrations du genre
NumProduit = NumClient * NumFournisseur +3
La question est donc : comment est-il possible de définir des types spécifiques pour les numéros de client, etc. de sorte que tout mélange provoque une erreur à la compilation ?
Merci d'avance, Gilbert
Integer n'est pas une classe mais cela n'a aucune importance dans la
discussion...
Il serait peut-être possible d'utiliser des types spécifiques pour éviter
toute opération mais bien voir si le jeu en vaut la chandelle. L'exemple
donné ne me parait pas très réaliste (en gros, le développeur fait vraiment
n'importe quoi).
Concrètement NumProduit serait sans doute en lecture seule en lecture seule
(car attribution automatique par la bd) et le code ne compilerait pas à
cause de cela (et non pas à cause de l'opération).
Une autre solution serait d'utiliser un guid (mais si je pousse le
raisonnement à l'extrème, un développeur pourrait convertir le guid en
octets et en faire n'importe quoi...)
Pour l'instant je pense que ce point est exagéré et que le jeu est loin d'en
valoir la chandelle. Il y a sans doute bien d'autres points plus importants
à traiter...
--
Patrice
"Gilbert Tordeur" <gilbert.tordeur@orange.fr> a écrit dans le message de
groupe de discussion : eDYljSS5JHA.3968@TK2MSFTNGP03.phx.gbl...
Bonjour.
Nous utilisons tous des fichiers Clients, Fournisseurs, Produits ou
autres, dont les clés sont des nombres entiers banalisés (souvent
attribués automatiquement par notre base de données).
Dans les programmes, ces clés sont déclarées en Integer.
En fait, ce n'est pas terrible ! Cela permet d'écrire des aberrations du
genre
NumProduit = NumClient * NumFournisseur +3
La question est donc : comment est-il possible de définir des types
spécifiques pour les numéros de client, etc. de sorte que tout mélange
provoque une erreur à la compilation ?
Integer n'est pas une classe mais cela n'a aucune importance dans la discussion...
Il serait peut-être possible d'utiliser des types spécifiques pour éviter toute opération mais bien voir si le jeu en vaut la chandelle. L'exemple donné ne me parait pas très réaliste (en gros, le développeur fait vraiment n'importe quoi).
Concrètement NumProduit serait sans doute en lecture seule en lecture seule (car attribution automatique par la bd) et le code ne compilerait pas à cause de cela (et non pas à cause de l'opération).
Une autre solution serait d'utiliser un guid (mais si je pousse le raisonnement à l'extrème, un développeur pourrait convertir le guid en octets et en faire n'importe quoi...)
Pour l'instant je pense que ce point est exagéré et que le jeu est loin d'en valoir la chandelle. Il y a sans doute bien d'autres points plus importants à traiter... --
Patrice
"Gilbert Tordeur" a écrit dans le message de groupe de discussion :
Bonjour.
Nous utilisons tous des fichiers Clients, Fournisseurs, Produits ou autres, dont les clés sont des nombres entiers banalisés (souvent attribués automatiquement par notre base de données).
Dans les programmes, ces clés sont déclarées en Integer.
En fait, ce n'est pas terrible ! Cela permet d'écrire des aberrations du genre
NumProduit = NumClient * NumFournisseur +3
La question est donc : comment est-il possible de définir des types spécifiques pour les numéros de client, etc. de sorte que tout mélange provoque une erreur à la compilation ?
