在这种情况下，使用 .Net Lazy 类是否太过分了？

Question

我最近了解了 .Net 中的 Lazy 类，并且可能已经过度使用它了。我在下面有一个示例，其中可以以急切的方式对事物进行评估，但是如果一遍又一遍地调用，这将导致重复相同的计算。在这个特定的示例中，使用 Lazy 的成本可能无法证明其好处，而且我对此不确定，因为我还不了解 lambda 和延迟调用到底有多昂贵。我喜欢使用链式惰性属性，因为我可以将复杂的逻辑分解成小的、可管理的块。我也不再需要考虑初始化东西的最佳位置在哪里 - 我需要知道的是，如果我不使用它们，东西将不会被初始化，并且在我开始使用它们之前将被初始化一次。然而，一旦我开始使用惰性和 lambda，原来的简单类现在变得更加复杂。我无法客观地决定什么时候这是合理的，什么时候这在复杂性、可读性、可能的速度方面是过度的。您的一般建议是什么？

    // This is set once during initialization.
    // The other 3 properties are derived from this one.
    // Ends in .dat
    public string DatFileName
    {
        get;
        private set;
    }

    private Lazy<string> DatFileBase
    {
        get
        {
            // Removes .dat
            return new Lazy<string>(() => Path.GetFileNameWithoutExtension(this.DatFileName));
        }
    }

    public Lazy<string> MicrosoftFormatName
    {
        get
        {
            return new Lazy<string>(() => this.DatFileBase + "_m.fmt");
        }
    }

    public Lazy<string> OracleFormatName
    {
        get
        {
            return new Lazy<string>(() => this.DatFileBase + "_o.fmt");
        }
    }

Answer 1

这可能有点矫枉过正了。

当泛型类型的创建或评估成本昂贵时，和/或当依赖类的每次使用中并不总是需要泛型类型时，通常应使用惰性。

很可能，任何在这里调用 getter 的东西都将在调用 getter 后立即需要一个实际的字符串值。在这种情况下返回 Lazy 是不必要的，因为调用代码将立即评估 Lazy 实例以获得它真正需要的内容。懒惰的“及时”本质在这里被浪费了，因此，YAGNI（你不需要它）。

也就是说，Lazy 固有的“开销”并不是那么多。 Lazy 只不过是一个引用将生成泛型类型的 lambda 的类。 Lambda 的定义和执行成本相对较低；它们只是方法，在编译时由 CLR 指定一个混搭名称。额外类的实例化是主要的问题，即使如此，它也并不可怕。然而，从编码和性能的角度来看，这都是不必要的开销。

Answer 2

你说“我不再需要考虑初始化东西的最佳位置在哪里”。

这是一个不好的习惯。您应该确切地知道程序中发生了什么

当有一个对象需要传递但需要一些计算时，您应该Lazy。
所以只有当它被使用时才会被计算。

除此之外，您需要记住，使用惰性检索的对象不是请求时处于程序状态的对象。
仅当使用该对象时，您才会获得该对象本身。如果您获得对程序状态很重要的对象，那么稍后将很难调试。

Answer 3

这似乎并不是为了节省昂贵对象的创建/加载而使用 Lazy，而是为了（可能无意中）包装一些任意委托以延迟执行。您可能希望/打算派生属性 getter 返回的是 string，而不是 Lazy 对象。

如果调用代码看起来像

string fileName = MicrosoftFormatName.Value;

这样，那么显然没有意义，因为您立即“延迟加载”。

如果调用代码如下所示

var lazyName = MicrosoftFormatName; // Not yet evaluated
// some other stuff, maybe changing the value of DatFileName
string fileName2 = lazyName.Value;

，那么您可以看到在创建 lazyName 对象时，fileName2 可能无法确定。

在我看来，Lazy 不适用于公共属性；这里你的 getter 返回新的（如全新的、不同的、额外的）Lazy 对象，因此每个调用者将（可能）获得一个不同的 。价值！您的所有 Lazy 属性均取决于首次访问其 .Value 时设置的 DatFileName，因此您将总是需要考虑相对于每个派生属性的使用何时进行初始化。

请参阅 MSDN 文章“延迟初始化”，该文章创建了私有 Lazy 支持变量和公共属性 getter，如下所示：

get { return _privateLazyObject.Value; }

我可能猜测您的代码应该/可能喜欢什么，使用 Lazy 来定义您的“设置一次”基本属性：

// This is set up once (durinig object initialization) and
// evaluated once (the first time _datFileName.Value is accessed)
private Lazy<string> _datFileName = new Lazy<string>(() =>
    {
        string filename = null;
        //Insert initialization code here to determine filename
        return filename;
    });

// The other 3 properties are derived from this one.
// Ends in .dat
public string DatFileName
{
    get { return _datFileName.Value; }
    private set { _datFileName = new Lazy<string>(() => value); }
}

private string DatFileBase
{
    get { return Path.GetFileNameWithoutExtension(DatFileName); }
}

public string MicrosoftFormatName
{
    get { return DatFileBase + "_m.fmt"; }
}

public string OracleFormatName
{
    get { return DatFileBase + "_o.fmt"; }
}

Answer 4

使用Lazy来创建简单的字符串属性确实是一种矫枉过正。使用 lambda 参数初始化 Lazy 实例可能比执行单个字符串操作要昂贵得多。还有一个其他人尚未提及的更重要的论点 - 请记住，lambda 参数由编译器解析为相当复杂的结构，比字符串连接复杂得多。

Answer 5

另一个适合使用延迟加载的领域是可以在部分状态下使用的类型。例如，请考虑以下情况：

public class Artist
{
     public string Name { get; set; }
     public Lazy<Manager> Manager { get; internal set; }
}

在上面的示例中，消费者可能只需要利用我们的 Name 属性，但必须填充可能使用或可能不使用的字段，这可能是延迟加载的地方。我说可以不应该，因为在某些情况下，预先加载所有内容可能会更具性能......具体取决于您的应用程序需要执行的操作。