devrait avoir un mot clé paresseux pour faciliter l'initialisation paresseuse?
EG P>
private string _backingField; public string LazyInitializeString { get { if (_backingField == null) _backingField = GetStringFromDatabase(); return _backingField; } }
3 Réponses :
Je ne connais pas un mot clé, mais il a maintenant un System.lazy
type.
code>. li>
- Il prend en charge un
Lambda Expression CODE> ou A méthode code> pour fournir une valeur. LI>
ul> Exemple: h2> xxx pré> test: h2> xxx pré> dans le code de test ci-dessus, getstringfromdatabase () code> est appelé une seule fois. Je pense que c'est exactement ce que vous voulez. P> EDIT: H2>
Après avoir commis des commentaires de @Dthorpe et @joe, tout ce que je peux dire, c'est le plus court, il peut être: p> xxx pré> Parce que le suivant ne compile pas: p> xxx pré> et cette propriété est le type de paresseux code > pas chaîne code>. Vous avez toujours besoin d'accéder à sa valeur en utilisant Lazyinitializestring.value code>. P> et, je suis ouvert à des suggestions sur la façon de le rendre plus court. P> P>
Mon esprit est toujours intact, mais je suis suffisamment impressionné par upvote.
N'est-ce pas exactement la même chose que l'affiche originale proposée? Vous avez exactement les mêmes étapes dans votre code que dans sa définition d'un magasin de support, implémentez le getter pour allouer la première utilisation et renvoyer la valeur mise en cache sur la suite obtient. Ce code ne semble pas tirer parti de toute paresse fournie par le type paresseux
@Dthorpe a raison - l'échantillon serait plus réaliste si vous affectez Lazysource lorsqu'il est déclaré, et supprimez le test pour NULL de la propriété Getter.
@DecyClone, je ne pense pas que vous devriez vous soucier de votre dernier échantillon à cause de il ne compile pas code>. Il ne compile pas à cause de
getstringfromdatabase code> n'est pas statique, mais de la même manière que la syntaxe d'origine de l'OP ne sera pas compilable pour le moment (même si nous ignorons le nouveau
paresseux code> mot-clé) , à cause de la même raison - méthode n'est pas statique.
@Snowbear: Je sais pourquoi le dernier code de code ne compile pas. J'ai fourni la solution la plus courte possible conformément à mes connaissances qui compilent et fonctionnent.
@DecyClone, je crois que vous savez pourquoi, je voulais juste dire que non compilable B> est aussi bien;)
Avez-vous envisagé d'utiliser system.lazy
?
public Lazy<String> LazyInitializeString = new Lazy<String>(() => { return GetStringFromDatabase(); });
Et la peine de mentionner que c'est en C # 4.0
Dans cet exemple, je pense que nouveau paresseux (getstringfromdatabase); code> devrait fonctionner - pas de supplément de Lambda et de type générique inféré. C # est génial.
@Jani: Cela ne fait pas partie de C # 4. Cela fait partie de .NET 4. Cela vaut la peine de différer la différence entre la version de la langue et du cadre.
@Jon, @jani - d'autant plus que cela est possible d'écrire vos propres versions de choses dans un cadre futur si vous avez besoin (je ne ferais pas sans ma 2.0 Hashset dans un projet 2.0, je maintiens) mais vous ne pouvez pas écrire votre propre caractéristiques de la langue dans la même mesure.
Je sais que paresseux
@Jonathan Parker, bien l'autre avantage de pouvoir écrire votre propre copie, vous pouvez écrire une version différente. Mon 2.0 Hashset n'est pas le même que le 3.5, parce que je voulais une fonctionnalité supplémentaire. De même, le Setbablelazy dans ma nouvelle réponse fait ce que vous voulez ici.
D'accord, vous dites dans un commentaire selon lequel Néanmoins, il est clair que nous voulons quelque chose dans ces lignes - nous avons déjà une syntaxe pour décrire une action à appeler, mais pas appelée immédiatement (en effet, nous avons trois; lambda, création de délégué et nom de méthode nue comme raccourci vers Ce dernier - la dernière chose dont nous avons besoin est un quatrième). p> Mais nous pouvons rapidement mettre ensemble quelque chose qui fait cela. p> paresseux
.value code> sur elle.
private SettableLazy<string> _backingLazy = new SettableLazy<string>(GetStringFromDatabase);
public string LazyInitializeString
{
get
{
return _backingLazy;
}
set
{
_backingLazy = value;
}
}
Bien que ce soit bien, vous ne voudrez plus jamais utiliser une langue qui comptait 1000 caractéristiques intéressantes parce que personne ne pourrait jamais les apprendre. Considérant à quel point il est facile d'avoir la fonctionnalité (
paresseux code>, propriétés (comme vous montrez, bien que ce ne soit pas thread-coffre-fort), des initialisateurs statiques), il n'est pas susceptible de se présenter dans le Langue.
Je crois que vous devriez changer votre premier échantillon de code. Il est incorrect non seulement du fait d'un mot-clé
manquant code> paresseux, mais également à l'aide de méthodes d'instance dans les initialisateurs de champ.