Cette question a dans le dos de mon esprit pendant un certain temps, désolé si elle semble subjective. Il y a quelques inconvénients à l'utilisation bool dans les propriétés publiques et les constructeurs pour les objets de données. Considérez le code suivant comme un exemple
Utilisation bool:. Strong> p> Room r = new Room ("101", BookingStatus.Bookable);
4 Réponses :
dans son livre refactoring , Martin Fowler explique pourquoi il pense que Enums sont une odeur de code, et je ne peux que d'accord. Dans votre exemple, une meilleure approche serait de faire une classe de chambre abstraite: Ensuite, vous pouvez faire des classes de bookeroom et nonbookable dérivées. P> public class BookableRoom : Room
{
public override bool Bookable
{
get { return true; }
}
}
public class NonBookableRoom : Room
{
public override bool Bookable
{
get { return false; }
}
}
Point fort et une méthode que j'ai utilisée d'autre où. Je présume que cela ne fonctionnerait pas très bien avec quelque chose comme le cadre d'entité? Cependant, ce serait certainement très bien sur quelque chose comme une liste SharePoint.
Pourquoi déclarez-vous que c'est une meilleure approche? Pour moi, cela ressemble tout à fait plus de complexité. Je pense que le principe du baiser est approprié ici.
Le livre fournit une description complète :)
Je suis d'accord avec @nightCoder et je suis confus par la sélection de cette réponse. L'OP était-elle préoccupée par le fait qu'une énumération ne serait pas une solution complexe et verbeuse assez de retourner un seul morceau? Nous devrions donc faire cuire chaque état d'exécution de chaque type d'objet dans notre code source? Ce que fait Martin Fowler dit pour défendre cette pratique?
Pour être clair, quel genre d'énums sont-ils en train de parler de M. Fowler? Autant que j'aime C #, c'est que les énums ne sont pas particulièrement puissants ni cohérents. Je trouve que Ada-Esque Enums est très utile, mais je suis ouvert aux arguments.
Ensuite, que faites-vous lorsque vous avez plusieurs propriétés de l'état? Ajouter encore plus de cours? Ajouter des cours fournissant chaque combinaison d'état possible?
L'exemple n'est peut-être pas le meilleur, mais cette réponse a une certaine sagesse. Jetez un coup d'œil à logiciel .stackexchange.com / Questions / 300080 / ... Pour une discussion ultérieure sur la raison pour laquelle Enums est généralement une odeur de code. En termes simples, il ne s'agit pas simplement de la représentation des données, il s'agit également d'un comportement. Si vous avez un type ouvert, cela pourrait être changé à l'avenir et qui ont un comportement distinct à chacune de ses valeurs possibles, il est tout simplement plus clair et plus robuste d'utiliser le polymorphisme, par opposition à une énumération et continuez de passer à autre chose Autour des valeurs Enum ...
IH Il y a une chance que, à l'avenir, il pourrait y avoir plus que les deux options initiales, l'ajout d'une troisième option à un ENum est beaucoup moins de travail puis changeant tout bool à l'énum.
C'est ce qu'il a déjà dit dans sa réponse (deuxième point dans la liste des balles).
Sauf pour le "plan d'avenir" aspect.
Tout simplement en raison de la lisibilité et de la compréhension du code, je vais aller pour l'énum au lieu de booléen.
comparer Aussi comme ce que la FFORW a mentionné, au cas où vous pourriez avoir besoin d'ajouter plus d'options, Enum serait plus facile à changer. bookingstatus.bookable et vrai , bien sûr, vous comprenez plus de lecture bookingstatus.bookable . .
Qu'en est-il de la sécurité de type? Un énumé empêcherait toute vieille valeur booléenne d'être abandonnée dans un paramètre Enum.
C'est aussi préférable de maintenir. Les changements sont plus petits lorsque vous utilisez Enum si un nouveau type de bookingstatus est inventé
Pour une propriété, je serais probablement d'accord. Dans 'Nettoyer le code', il est indiqué (correctement) que lorsque cela ressemble à ce que cela ressemble à: à la place, il serait beaucoup plus lisible : qui fait ensuite ressembler à l'appel: (N'oubliez pas que ce n'est qu'un exemple de la façon dont les paramètres Bool Masquer l'intention; il existe probablement de meilleurs moyens de mettre en œuvre le code ci-dessus.) Dans votre cas particulier, remarquez la différence entre les deux appels de constructeur: BOOL s est masquez l'intention lorsqu'il est utilisé comme paramètre. Par exemple, une méthode de formatage peut ressembler à:
De plus, vous ne pouvez pas mettre une variable contenant la valeur audacieuse de volonté dans la fente de paramètres «italique» lors de l'utilisation de l'ENUMS. :) Tapez la sécurité.
// string; "101" Quoi? Ajoutez quelques cordes supplémentaires et vous êtes dans la même position qu'avec un bool. Donc que fais-tu? Vous regardez la définition de la méthode.
@Stijn a accepté. Ne pas lire une méthode Signature n'est pas une excuse pour ne pas comprendre une signature de méthode.
Opinion: Cela semble être ce n'est pas le meilleur exemple - si c'est une vraie question oui / aucune question, alors les bools sont appropriés. Bien que vous niez correctement vos propriétés conformément à la convention (c'est-à-dire «isbookable») - un meilleur exemple est une question non-oui ou aucune question, comme pour le sexe ou les unités de mesure, etc. - même si vous ne reconnaissez que deux états (pouces vs cm ou mâle vs femelle), vous devez utiliser un énumé, car ceux-ci ne sont définitivement pas des questions «oui ou non» (même si vous pourriez les faire dans des questions oui / non, ils ne sont pas et que chacun peut être élargi pour soutenir plus d'états).