Je suis un grand fan de la vérification de type statique. Cela vous empêche de faire des erreurs stupides comme ceci:
// java code
Adult a = new Adult();
a.setAge("Roger"); //static type checker would complain
a.setName(42); //and here too
Mais cela ne vous empêche pas de faire des erreurs stupides comme celle-ci:
Adult a = new Adult();
// obviously you've mixed up these fields, but type checker won't complain
a.setAge(150); // nobody's ever lived this old
a.setWeight(42); // a 42lb adult would have serious health issues
Le problème survient lorsque vous utilisez le même type pour représenter des types d'informations évidemment différents. Je pensais qu'une bonne solution à cela serait d'étendre la Integer
classe, juste pour éviter les erreurs de logique métier, mais pas pour ajouter des fonctionnalités. Par exemple:
class Age extends Integer{};
class Pounds extends Integer{};
class Adult{
...
public void setAge(Age age){..}
public void setWeight(Pounds pounds){...}
}
Adult a = new Adult();
a.setAge(new Age(42));
a.setWeight(new Pounds(150));
Est-ce considéré comme une bonne pratique? Ou y a-t-il des problèmes d'ingénierie imprévus en cours de route avec une conception aussi restrictive?
new Age(...)
objet, vous ne pouvez pas l'affecter de manière incorrecte à une variable de type Weight
à d'autres endroits. Cela réduit le nombre d'endroits où des erreurs peuvent se produire.
a.SetAge( new Age(150) )
compilerez toujours pas ?