c# - 在这种情况下，使用 .Net Lazy 类是否有点矫枉过正？

Question

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

    // 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 实例以获得它真正需要的东西。 Lazy 的“及时”特性在这里被浪费了，因此，YAGNI(你不需要它)。

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