Le préfixe "membre" est une sorte de détail d'implémentation. Il détourne votre attention du domaine du problème vers le domaine de la solution technique qui biaise votre esprit lorsque vous pensez à des refactorings possibles. - moi
pouvez-vous expliquer davantage? C'est la seule raison pour laquelle j'ai vu pourquoi ne pas utiliser le préfixe et je ne le comprends pas ... (par ce que je veux dire, les autres choses que les gens disent sont des raisons pour lesquelles je n'ai pas à l'utiliser, ce qui n'est pas la même chose que pourquoi je ne devrais pas) - Betty Crokker
Mon point est d'étendre les réponses de @CandiedOrange et @Ewan.
Les préfixes rendent le refactoring plus difficile
À mesure que votre code évolue, les variables et les méthodes peuvent changer leur portée. Par exemple. vous pouvez créer une méthode privée et découvrir plus tard qu'elle devrait également être disponible pour d'autres (nouvelles) classes. Des paramètres similaires et des variables locales peuvent se produire.
Supposons que vous créez un calculateur de taxes. Selon le principe de l' étendue de visibilité du bail pour les variables, vous commencez avec une méthode qui prend à la fois le taux de taxe et la valeur de base comme paramètres:
(l'exemple peut ressembler à Java-ish ...)
class TaxCalculator{
double Calculate(double p_TaxRateInpercent, double p_BaseValue){
return (100+p_TaxRateInpercent)/100 * p_BaseValue;
}
}
ensuite vous devez implémenter l'opération inverse et selon TDD vous le faites avec le moins d'effort:
class TaxCalculator{
double Calculate(double p_TaxRateInpercent, double p_BaseValue){
return (100+p_TaxRateInpercent)/100 * p_BaseValue;
}
double CalculateBase(double p_TaxRateInpercent, double p_TaxedValue){
return p_TaxedValue/((100+p_TaxRateInpercent)/100);
}
}
TDD veut que vous refactorisez le code pour le rendre plus propre, ce qui revient à réduire la liste des paramètres des deux méthodes.
(Oui, vous extrairez d'abord le calcul doublé, mais permettez-moi de comprendre mon point ...)
La solution évidente est de changer le taux d'imposition en une variable membre en le passant comme paramètre constructeur.
class TaxCalculator{
double m_TaxRateInpercent;
TaxCalculator(double p_TaxRateInpercent){
m_TaxRateInpercent = p_TaxRateInpercent;
}
double Calculate(double p_BaseValue){
return (100+m_TaxRateInpercent)/100 * p_BaseValue;
}
double CalculateBase(double p_TaxedValue){
return p_TaxedValue/((100+m_TaxRateInpercent)/100);
}
}
Comme vous pouvez le voir, nous avons dû changer toutes les lignes de nos méthodes existantes (toute ligne que nous avions l'habitude p_TaxRateInpercent
d'être exacte.
Le problème est que vous n'avez aucun support de votre IDE pour faire le changement de nom dans toute la classe. La seule aide à rechercher / remplacer qui changera également le constructeur ou toute partie qui contient accidentellement la chaîne p_TaxRateInpercent
.
Vous IDE pouvez proposer une modification de ... refactoring pour les noms de variables non définis, mais cela peut être limité à la portée de la méthode
Sans le préfixe, seules les signatures de méthode auraient changé. Aucun changement de nom n'aurait été nécessaire.
Les préfixes encombrent l'historique SCM lorsqu'ils sont modifiés
Le SCM enregistre également le changement de préfixe comme des changements dans la logique bien que la logique n'ait pas changé! L'histoire des SCM est encombrée de ce changement technique qui cache ce qui est important et augmente le risque de conflits avec les changements (réels) des autres.
this
mot-clé? Ne pourriez-vous pas vous référer aux membres utilisantthis
, commethis.count
?