J'ai récemment découvert sur les propriétés automatiques et les aime beaucoup. En ce moment, j'essaie de les utiliser partout où je peux. Pas vraiment pour pouvoir les utiliser partout, mais plus pour voir à quel point ils travaillent dans la plupart des situations.
Maintenant, je fais un singleton et pensé: "Hé, essayons également les propriétés automatiques ici". Donc, ma question est de: "Est-ce une bonne idée de mettre en œuvre un singleton comme celui-ci? " Je ne demande pas si un singleton en général est une bonne idée.
6 Réponses :
Je ne vois aucune raison pour laquelle cela ne serait pas correct. Après tout, les propriétés automatiques ne sont que du sucre syntaxique pour les accesseurs pour un champ de support privé (généré par compilateur).
Bien sûr, je ne vois aucun problème avec ça.
Je ne le ferais pas personnellement. Je n'aime pas utiliser les propriétés implémentées automatiquement avec un setter privé que vous n'appelez jamais où vraiment em> vous souhaitez une propriété en lecture seule sur une variable en lecture seule. Ce n'est qu'une dernière ligne de code pour être plus explicite sur ce que vous voulez dire: de cette façon de non-un tenté em> pour changer la classe Singleton pour réaffecter le propriété ou la variable, car le compilateur les arrêtera. Ils devaient ajouter un seigteur et / ou rendre la variable non-réadonnée, qui est un changement plus important, ce qui, espérons-le, ils reconsidèrent. P> En d'autres termes: P> à partir de C # 6, cela est plus facile avec les propriétés appliquées automatiquement en lecture seule: P>
public sealed class MySingleton
{
public static MySingleton MySingleton { get; } = new MySingleton();
private MySingleton() {}
static MySingleton() {}
}
Je suis fortement en désaccord. Les propriétés automatiques ont été inventées pour rendre le code plus succinct, ce qui rend le code plus lisible. L'argument selon lequel il est un peu plus difficile pour que les autres de gâcher votre conception ne sont pas très convaincants IMHO.
@Philippe: Les propriétés automatiques ont été inventées pour rendre le code plus succinct où le code de remplacement est équivalent à l'original . Il n'y a pas d'équivalence de ce type ici: vous remplacez une propriété en lecture seule avec une lecture en lecture-écriture, même s'il s'agit d'un setter privé. Cela peut sembler trivial, mais je préfère que mon code exprime mes intentions - et mon intention serait que la valeur ne peut être fixée qu'une seule fois. La propriété mise en œuvre automatiquement exprime une intention différente.
Vous avez un point sur la "intention" du setter, mais à la fin, au consommateur de la classe, il n'y a pas de différence que ce soit. Avoir une propriété automatique avec un setter privé est excédément comme ayant une propriété en lecture seule avec un champ de support privé. Bien sûr, il compile un code différent, mais il est essentiellement la même chose du point de vue du consommateur de la classe. Maintenant, je dois me gifler, car je n'ai jamais aimé les propriétés automatiques et maintenant je défends son utilisation (mais c'est un sujet pour une autre question que je suppose)
@Philippe: Ainsi, tant que l'API est tout droit au consommateur , peu importe la mise en œuvre? Qu'en est-il du responsable? J'aime mon code pour documenter l'intention de la prochaine personne qui va regarder le code source, pas seulement les consommateurs.
Dans le cas d'un motif bien connu, l'intention «est généralement très claire, donc je ne pense pas que ce soit un problème ici. Mon point est vraiment: "moins de code" est généralement "meilleur code", tant qu'il entraîne une meilleure lisibilité. Mais je ne veux pas commencer un argument sans fin. Vos points sont valables, mais dans ce cas particulier, je pense que le code de l'OP est plus lisible.
Bonjour - Le nouveau sucre syntaxique en C # rend ça ok to SE la propriété auto comme ça, n'est-ce pas? Static public Somesingleton instance {Obtenir; } = nouveau somesingleton ();
@Bartosz: Oui, ce serait bien à partir de C # 6.
@ Jonskeet fait que l'auto-propriété interfère avec la sécurité / la paresse du fil? Il suffit de lire dans votre site Web C # en profondeur Site Web et en regardant Solution no. 4
@Thomas: Nope, il ne faut pas faire - c'est une propriété simple soutenue par un champ en lecture seule.
Je voudrais aborder cela d'une direction légèrement différente que Jon. Quelques de savoir si l'objet est un singleton, est-il logiquement mieux modelé comme une propriété en première place? Les propriétés sont censées représenter ... des propriétés. (Capitaine évident frappe à nouveau!) Vous savez. Couleur. Longueur. Hauteur. Nom. Parent. Toutes les choses que vous envisagez logiquement d'être une propriété d'une chose. Je ne peux pas concevoir un d'un objet logique un singleton . Peut-être que vous avez proposé un scénario dont je n'ai pas pensé; Je n'ai pas encore eu de régime avec le Dr Pepper ce matin. Mais je suis méfiant que c'est un abus de la sémantique modèle. Pouvez-vous décrire ce que le singleton est, et pourquoi vous croyez être une propriété de quelque chose? Tout ce que dit moi-même, j'utilise moi-même ce modèle fréquemment; Habituellement comme ceci: est "vide" logiquement une propriété d'une pile immuable? Non, voici ici l'avantage convaincant de pouvoir dire l'emporte sur mon désir de propriétés logiquement être propriétés. Dire semble juste bizarre. s'il est mieux dans ce cas d'avoir un champ lison et une propriété régulière, ou un CTOR STATIC et un Autoprop, semble être moins une question intéressante que de la faire une propriété en premier lieu. Dans une humeur "puriste", je serais probablement dans le contexte de Jon et en faire un champ réadien. Mais j'utilise également fréquemment le motif de fabrication de véhicules autoprops avec des setters privés pour des objets logiquement immuables, juste hors de la paresse. Comment est-ce pour prendre tous les côtés d'une question?
Hum ... intéressant. Je n'ai jamais vraiment considéré ses propriétés de cette manière. Pour moi, ils ont toujours été un remplacement des méthodes d'accesseur. D'une certaine manière, j'ai consulté les méthodes d'accesseur afin d'améliorer les champs publics (partiellement masquez, mettre en interface, ajoutez des informations de contrôle). Et ensuite les propriétés pour pouvoir obtenir un moyen plus intuitif que les getters et les setters. Donc, pour moi, une propriété ne doit jamais être logiquement une propriété des choses que la classe représente. Pour moi, une propriété est à quel point un champ ressemble de l'extérieur.
Pourriez-vous élaborer au profit de la syntaxe liée à la propriété dans votre immutatablestack énumérable.empty
@Lbushkin - Je suppose que "vides" vs "vide ()" vs "geempty ()" sont toutes assez petites différences. Je pense que "avantage convaincant" était une exagération! :-)
Propriété auto? Non, je ne voudrais pas utiliser un setter sur un singleton, oui je l'ai fait. Je pense que vous voulez plus de contrôle sur celui-ci qu'une propriété automatique vous donnera.
... Les commentaires constructifs sont plus que les bienvenus ici, s'il vous plaît. Cela ressemble à une émission courageuse (ou stupide) dans cette société estimée ... p>
Mon scénario, une application WPF qui a un projet actuel que peut être chargé et enregistré. Les paramètres actuels du projet sont utilisés dans toute l'application ... P>
inotifyproperTychanged code>. li>
- J'utilise aussi FDODER.PROPERTYCHANGED mais cela ne fait pas de modifications de propriété statique, donc
NotifyStaticPropertyChanged code>. li>
-
inotifypropertychandesd code> fonctionne bien avec les liaisons WPF sur les propriétés du singleton. Li>
- Une instance des paramètres
code> est [de] sérialisé à l'aide de json.net, d'où l'attribut [jSonignore] code> sur le singleton. Je la valide avant de le charger dans le singleton ou le sauvegarde sur le disque. Li>
- Le logger est Serilog . Vous vous connectez, non? LI>
- The Singleton est
Public Code> avec un Public code> Getter Parce que les liaisons WPF fonctionnent uniquement sur les propriétés publiques. Le setter code> interne code> ne l'affecte pas. Toutes les propriétés de Paramètres CODE> sont publiques pour la liaison WPF. LI>
ul> J'ai laissé tout le "bruit" dans le code parce que certains peuvent le trouver utiles. p> xxx pré> utilisation pour définir le singleton sur un projet nouvellement chargé, Paramètres code> est simplement P> Settings settings = new Settings();
// load, save, deserialize, set properties, go nuts
Settings.CurrentSettings = settings;
Calculer + Syntaxe alternative avec style Lambda (> = C # 6) AKA Propriété calculée (AKA EXPRESS-EXPRESSITED MEMBRE):
Le code est fonctionnellement équivalent à la réponse de Jon Skeet, ici encore une fois avec "instance" avec "instance" . Je ne m'attends pas à des félicitations pour cela, mais je pense que cette opération mise à jour avec une explication à un endroit est la peine, car cette question et réponses c # 6 étendent l'ancien fil fermé où des variations de singleton ont été discutées. < P> Vous pouvez affirmer que le style automatique de la propriété avec un ensemble explicitement manquant montre plus d'intention d'une propriété en lecture seule, mais à la fin, il est basé sur le style, et les deux styles sont courants dans le C # moderne. < Pré> xxx
Voici tous les détails et référence historique au même endroit:
discussion sur la paresseuse: http://csharpindepth.com/articles/general/beforefieldinit.aspx
Résumé simplifié: la mise en œuvre ci-dessus se comporte paresseux tant qu'aucun autre champ statique / propriétés ne sont introduits dans la classe.
(Mais c'est une zone qui peut être une zone de mise en œuvre .Net - dépendante de la mise en œuvre.)
discussion concernant différentes implémentations de singleton et de sécurité de thread (styles de c # plus anciens): http://csharpindepth.com/articles/general/singleton.aspx
fil d'origine (fermé): singleton modèle pour C #