17-07-2013, 05:15 PM
Citation :Non mais si tu comptes les développeurs malveillants c'est facileIroniquement, oui, parce que justement, si on considère que les développeurs sont malveilants alors cela devient plutôt compliqué :p
La malveillance peut être volontaire (pirate, usurpateur, employé mécontent, troll...) ou involontaire (oublis, changement d'habitude, développeur inexpérimenté...).
Ne pas considérer les développeurs comme "malveillants" revient à ne pas considérer les utilisateurs du site web comme "malveilants". Pourtant, je suis certain que tu contrôles tes utilisateurs avant qu'ils ne fassent certains changement sur ton site (login et password requis par exemple).
Ton cas d'exemple du C++ est un "security information disclosure" (dans l'OWASP top 10 je crois bien). Un private initialisé par le constructeur lui-même ne posera pas ce problème. En mots plus raides, si je définis la valeur du mot de passe "en dur" dans le constructeur, il ne sera jamais dévoilé.
En revanche, oui, si tu t'en fous, c'est pas la peine de te prendre la tête à mettre private/Public ou autre. Mais le développeur n'a pas forcément volontairement choisi de se planter... Ce que je veux dire par là, c'est que si tu fais 100% confiance au développeur, alors pourquoi ne pas tout mettre en public, sans se poser de question? Niveau habitude de developpement, ca me semble un peu léger que d'utiliser QUE du public, et aucune constante (une constante contraint le développeur!).
Si la façon d'utiliser la librairie ne te plait pas, tu appliques les DP, et tu te crée une façade ou un adapter qui se charge de changer tes habitudes de codage perso en habitudes de codage de la bibliothèque.
Heu... ops... Oui, c'est carrément HS ^^ Eyuup, je suis d'accord avec l'idée de l'alerte dans le getter magique, c'est une solution très jolie. Malheureusement, les développeurs qui sont assez consciencieux pour évincer les warnings sont rare... Le nombre de fois où j'ai entendu "Ouf, y'a que des warnings!" est impressionnant...!
Et pour en revenir au sujet, donc, je dirai pareil: c'est effectivement du code acceptable, mais il pourrait être plus strict et rigoureux.