1

我看到了很多 Fluent 风格 api 开发的例子，但有些时候我看到人们用接口实现 fluent，有些时候人们不使用接口，只使用直接的类。我认为人们使用流利风格的 api 只是因为使用链......意味着易于访问。所以我想知道流畅的api或性能实习生是否有其他好处。

这是小代码。

public class Coffee
{
    private bool _cream;

    public Coffee Make { get new Coffee(); }

    public Coffee WithCream()
    {
        _cream = true;
        return this;
    }

    public Coffee WithOuncesToServe(int ounces)
    {
        _ounces = ounces;
        return this;
    }
}

var myMorningCoffee = Coffee.Make.WithCream().WithOuncesToServe(16);
4

1 回答 1

1

在您的示例中，我认为语法（即“易用性”）是唯一的优势。但是例如 LINQ 方法的工作方式不同 - 方法不返回this，它们返回一个新实例。这显然会影响性能，但它使类成为不可变的，这在您推理代码时有很大帮助，它可以促进使用此类类的并行计算。

编辑（示例）：在这种情况下，您Coffee将看起来像这样（尽管它可能不是一个很好的示例，因为无论如何在这里使用流利的语法对我来说没有多大意义，更不用说使用新实例了）

public class Coffee
{
    private bool _cream;
    private int _ounces;

    // I really don't like this kind of instantiation,
    // but I kept it there and made static to make it work.
    public static Coffee Make { get new Coffee(); }

    public Coffee WithCream()
    {
        return new Coffee
        {
            _cream = true,
            _ounces = this._ounces
        }
    }

    public Coffee WithOuncesToServe(int ounces)
    {
        return new Coffee
        {
            _cream = this._cream,
            _ounces = ounces
        };
    }

但是当然，对于这样一个简单的类，最好使用带参数的构造函数，例如

public Coffee(int ounces, bool cream)

作为一个相反的例子，我记得一组方便的Dictionary扩展，可以流畅地添加项目，但无需创建新实例。就像是：

public static IDictionary<K, V> AddConditionally(
    this IDictionary<K, V> source,
    K key, V value)
{
    // Real-life implementation would contain more checks etc.
    if(!source.ContainsKey(key))
        source.Add(key, value);

    return source;
}

例如，您可以使用它来用一些初始数据填充字典

var dict = new Dictionary<int, int>()
    .AddConditionally(0,1)
    .AddConditionally(1,1)
    .AddConditionally(2,1)
    .AddConditionally(3,1);
于 2012-12-05T08:33:22.610 回答