C'est une procédure récursive doit vérifier tous ses arguments avant de se relancer elle-meme / de faire ce qu'elle doit (l'un, l'autre ou les deux). Relancée elle revérifiera ses arguments. Du coup les performances se dégradent. En objet j'ai une méthode récursive privée ou protégée (les jours ou je suis généreux) et un wraper public qui fait les vérifications une seule fois et appelle la récursion. Le probleme d'une fonction n'est pas de transmettre des parametres corrects (surtout à elle-meme), c'est de les recevoir de potentiellement n'importe quel goret et de savoir planter glorieusement sans corrompre les informations.Je vois pas en quoi ca gène pour la récursivité : si tu t'assures que ce que tu transmets est correct, et que ta fonction produit un résultat correct, alors pas de soucis pour la récursivité... Tout le reste, c'est du pipeau !
Les classes ont proposé un modèle cohérent pour gérer ce problème avec "des bonne manière de faire". En procédural, ben moi j'attends. On peut s'imposer une hygiène de codage de façon volontaire ou l'imposer aux autres avec des classes et des portées. N'oublions pas que le goret, contrairement à la croyance est un animal plutôt propre sur lui.
non un trou de sécurité est une fonctionnalité non maitrisée qui permet dans les faits à un utilisateur d’accéder à des informations sans y être habilité ou a modifier le fonctionnement normal d'une application. Le paradigme objet permet d'avoir des points d'entrée identifiés dans un programme donc réduit la surface d'exposition du code. Enfin je suis pas expert en sécu et je sais qu'un bon modèle ne fait pas tout.Un trou de sécu, c'est pas un autre mot pour désigner un morceau de code qui n'est pas développé dans les règles de l'art ?
moi j'arrete avec ce troll.
Partager