Notre base de code est ancienne et les nouveaux programmeurs, comme moi, apprennent rapidement à le faire comme il le fait dans un souci d'uniformité. Pensant que nous devons commencer quelque part, j'ai décidé de refactoriser une classe de détenteurs de données en tant que telle:
- Suppression des méthodes de définition et création de tous les champs
final
(je prends "final
c'est bien" axiomatiquement). Les setters ont été utilisés uniquement dans le constructeur, il s'avère que cela n'a donc eu aucun effet secondaire. - Introduit une classe Builder
La classe Builder était nécessaire parce que le constructeur (qui est à l'origine de la refactorisation) s'étend sur environ 3 lignes de code. Il a beaucoup de paramètres.
Par chance, un de mes coéquipiers travaillait sur un autre module et avait besoin des setters, car les valeurs dont il avait besoin sont devenues disponibles à différents moments du flux. Ainsi, le code ressemblait à ceci:
public void foo(Bar bar){
//do stuff
bar.setA(stuff);
//do more stuff
bar.setB(moreStuff);
}
J'ai soutenu qu'il devrait utiliser le générateur à la place, car se débarrasser des setters permet aux champs de rester immuables (ils m'ont déjà entendu parler de l'immuabilité auparavant), et aussi parce que les constructeurs permettent à la création d'objets d'être transactionnelle. J'ai esquissé le pseudocode suivant:
public void foo(Bar bar){
try{
bar.setA(a);
//enter exception-throwing stuff
bar.setB(b);
}catch(){}
}
Si cette exception se déclenche, bar
les données seront corrompues, ce qui aurait été évité avec un générateur:
public Bar foo(){
Builder builder=new Builder();
try{
builder.setA(a);
//dangerous stuff;
builder.setB(b);
//more dangerous stuff
builder.setC(c);
return builder.build();
}catch(){}
return null;
}
Mes coéquipiers ont répliqué que l'exception en question ne se déclenchera jamais, ce qui est assez juste pour ce domaine particulier du code, mais je crois qu'il manque la forêt pour l'arbre.
Le compromis était de revenir à l'ancienne solution, à savoir utiliser un constructeur sans paramètres et tout régler avec des setters selon les besoins. La raison était que cette solution suit le principe KISS, que le mien viole.
Je suis nouveau dans cette entreprise (moins de 6 mois) et pleinement conscient que j'ai perdu celle-ci. Ma ou mes questions sont:
- Y a-t-il un autre argument pour utiliser Builders au lieu de "l'ancienne méthode"?
- Le changement que je propose en vaut-il vraiment la peine?
mais réellement,
- Avez-vous des conseils pour mieux présenter de tels arguments lorsque vous préconisez d'essayer quelque chose de nouveau?
setA
?