实现“LazyProperty”类 – 这是一个好主意吗？
我经常发现自己正在编写一个懒惰评估的属性。 就像是：
if (backingField == null) backingField = SomeOperation(); return backingField; 代码不多，但如果你有很多属性，它会重复很多。
我正在考虑定义一个名为LazyProperty的类：
public class LazyProperty { private readonly Func getter; public LazyProperty(Func getter) { this.getter = getter; } private bool loaded = false; private T propertyValue; public T Value { get { if (!loaded) { propertyValue = getter(); loaded = true; } return propertyValue; } } public static implicit operator T(LazyProperty rhs) { return rhs.Value; } }
这将使我能够初始化这样的字段：
first = new LazyProperty(() => new HeavyObject { MyProperty = Value });
然后财产的主体可以减少到：
public HeavyObject First { get { return first; } }
这将被大多数公司使用，因为它将进入我们大多数产品共享的公共类库。
我不能决定这是不是一个好主意。 我认为这些解决方案有一些优点，例如：
- 更少的代码
- 更漂亮的代码
在缺点方面，查看代码并确切地确定发生了什么会更加困难 – 特别是如果开发人员不熟悉LazyProperty类。
你怎么看 ？ 这是个好主意还是我应该抛弃它？ 此外，隐式运算符是一个好主意，或者如果您应该使用此类，您是否更愿意显式使用Value属性？
欢迎提出意见和建议:-)
只是过于迂腐：
您提出的避免重复代码的解决方案：
private LazyProperty first = new LazyProperty (() => new HeavyObject { MyProperty = Value }); public HeavyObject First { get { return first; } }
实际上是比你不想重复的代码更多的字符：
private HeavyObject first; public HeavyObject First { get { if (first == null) first = new HeavyObject { MyProperty = Value }; return first; } }
除此之外，我认为隐式演员使代码很难理解。 我不会猜到一个简单地返回的方法，实际上最终会创建一个HeavyObject。 我至少会删除隐式转换并首先返回。来自该属性的值。
根本不要这样做。
一般情况下，使用这种惰性初始化属性是一种有效的设计选择： SomeOperation(); 是一个昂贵的操作（就I / O而言，就像它需要数据库命中或计算时），当你确定你通常不需要访问它。
也就是说，默认情况下你应该进行急切的初始化，当分析器说它是你的瓶颈时，然后将其更改为延迟初始化。
如果你觉得有必要创造这种抽象，那就是一种气味。
当然，您至少希望LazyPropery成为值类型，否则您为系统中的每个“延迟加载”属性添加了内存和GC压力。
另外，multithreading场景呢？ 考虑两个线程同时请求属性。 如果没有锁定，您可能会创建底层属性的两个实例。 为避免锁定常见情况，您需要执行双重检查锁定。
我更喜欢第一个代码，因为a）它是具有属性的常见模式，我立即理解它，并且b）你提出的观点：没有隐藏的魔法，你必须去查找，以了解何时何地正在获得价值。
我喜欢这个想法，因为它的代码更少，更优雅，但我会非常担心它很难看到并告诉我们发生了什么。 我认为它的唯一方法是使用“懒惰”方式设置变量约定，并在任何使用它的地方进行注释。 现在不会有编译器或任何会强制执行这些规则的东西，所以仍然是YMMV。
最后，对我而言，这样的决定归结为谁将会关注它以及那些程序员的质量。 如果你可以相信你的开发人员使用它并且评论得很好，那就去吧，但如果没有，你最好以易于理解和遵循的方式做到这一点。 /我的2cents
我不认为担心开发人员不理解是反对做这样的事情的好理由……
如果你认为那么你就不能做任何事情，因为害怕有人不理解你做了什么
您可以在中央存储库中编写教程或其他内容，我们在这里有这些笔记的wiki
总的来说，我认为这是一个很好的实现想法（不想开始讨论延迟加载是否是一个好主意）
在这种情况下我做的是创建一个Visual Studio代码片段 。 我认为那是你真正应该做的。
例如，当我创建ASP.NET控件时，我经常会有很多数据存储在ViewState中，所以我创建了一个这样的代码片段：
public Type Value { get { if(ViewState["key"] == null) ViewState["key"] = someDefaultValue; return (Type)ViewState["key"]; } set{ ViewState["key"] = value; } }
这样，只需要一点工作就可以轻松创建代码（定义类型，键，名称和默认值）。 它是可重用的，但是你没有其他开发人员可能不理解的复杂代码的缺点。
我喜欢你的解决方案，因为它非常聪明，但我不认为你通过使用它赢得了很多。 延迟加载公共属性中的私有字段绝对是可以复制代码的地方。 然而，这一直是我使用的模式，而不是需要重构为公共场所的代码。
如果您进行任何序列化，您的方法将来可能成为一个问题。 最初，了解您使用自定义类型执行的操作更令人困惑。
总的来说，我赞赏你的尝试，并欣赏它的聪明，但建议你恢复原来的解决方案，原因如上所述。
就个人而言，我认为LazyProperty类没有提供足够的价值来certificate使用它，特别是考虑到将它用于值类型的缺点（正如Kent所提到的）。 如果你需要其他function（比如使它成为multithreading），它可能被称为ThreadSafeLazyProperty类。
关于隐式属性，我更喜欢“Value”属性。 这是一个更多的打字，但对我来说更清楚。
我认为这是一个有趣的想法。 首先，我建议您从调用代码中隐藏Lazy Property，您不希望泄漏到您的域模型中它是懒惰的。 你用隐式运算符做的就是这样。
我喜欢你如何使用这种方法来处理和抽象出锁定的细节，例如。 如果你这样做，那么我认为有价值和价值。 如果您确实为双锁模式添加锁定监视，则很容易出错。
您可以使用C＃迭代器。 以下文章解释了样本用法和使用它的优点。