实现"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而言,如需要数据库命中或计算时),当您确定通常不会需要访问它.

也就是说,默认情况下你应该进行急切的初始化,当分析器说它是你的瓶颈时,然后将其更改为延迟初始化.

如果你想要创造那种抽象的冲动,那就是一种气味.