14

我最近提出了一个有趣的问题,流畅的方法应该返回什么?他们应该改变当前对象的状态还是创建一个具有新状态的全新对象?

如果这个简短的描述不是很直观,这里有一个(不幸的是)冗长的例子。它是一个计算器。它执行非常繁重的计算,这就是他通过异步回调返回结果的原因:

public interface ICalculator {
    // because calcualations are too lengthy and run in separate thread
    // these methods do not return values directly, but do a callback
    // defined in IFluentParams
    void Add(); 
    void Mult();
    // ... and so on
}

因此,这是一个设置参数和回调的流畅接口:

public interface IFluentParams {
    IFluentParams WithA(int a);
    IFluentParams WithB(int b);
    IFluentParams WithReturnMethod(Action<int> callback);
    ICalculator GetCalculator();
}

对于这个接口实现,我有两个有趣的选择。我会展示他们两个,然后我会写出我认为他们每个人的好和坏。

所以,第一个是通常的,它返回这个

public class FluentThisCalc : IFluentParams {
    private int? _a;
    private int? _b;
    private Action<int> _callback;

    public IFluentParams WithA(int a) {
        _a = a;
        return this;
    }

    public IFluentParams WithB(int b) {
        _b = b;
        return this;
    }

    public IFluentParams WithReturnMethod(Action<int> callback) {
        _callback = callback;
        return this;
    }

    public ICalculator GetCalculator() {
        Validate();
        return new Calculator(_a, _b);
    }

    private void Validate() {
        if (!_a.HasValue)
            throw new ArgumentException("a");
        if (!_b.HasValue)
            throw new ArgumentException("bs");
    }
}

第二个版本更复杂,它在每次状态更改时返回一个新对象:

public class FluentNewCalc : IFluentParams {
    // internal structure with all data
    private struct Data {
        public int? A;
        public int? B;
        public Action<int> Callback;

        // good - data logic stays with data
        public void Validate() {
            if (!A.HasValue)
                throw new ArgumentException("a");
            if (!B.HasValue)
                throw new ArgumentException("b");
        }
    }

    private Data _data;

    public FluentNewCalc() {
    }

    // used only internally
    private FluentNewCalc(Data data) {
        _data = data;
    }

    public IFluentParams WithA(int a) {
        _data.A = a;
        return new FluentNewCalc(_data);
    }

    public IFluentParams WithB(int b) {
        _data.B = b;
        return new FluentNewCalc(_data);
    }

    public IFluentParams WithReturnMethod(Action<int> callback) {
        _data.Callback = callback;
        return new FluentNewCalc(_data);
    }

    public ICalculator GetCalculator() {
        Validate();
        return new Calculator(_data.A, _data.B);
    }

    private void Validate() {
        _data.Validate();
    }
}

他们如何比较:

专业第一(这个)版本:

  • 更容易和更短

  • 常用的

  • 似乎更节省内存

  • 还有什么?

临第二()版:

  • 将数据存储在单独的容器中,允许单独的数据逻辑和所有处理

  • 让我们可以轻松地修复部分数据,然后再填写其他数据并单独处理。看一看:

        var data = new FluentNewCalc()
            .WithA(1);
    
        Parallel.ForEach(new[] {1, 2, 3, 4, 5, 6, 7, 8}, b => {
            var dt = data
                .WithB(b)
                .WithReturnMethod(res => {/* some tricky actions */});
    
            // now, I have another data object for each value of b, 
            // and they have different callbacks.
            // if I were to do it with first version, I would have to create each 
            // and every data object from scratch
            var calc = dt.GetCalculator();
            calc.Add();
        });
    

第二个版本还有什么更好的?

  • 我可以像这样实现 WithXXX 方法:

    public IFluentParams WithXXX(int xxx) {
        var data = _data;
        data.XXX = xxx;
        return new FluentNewCalc(data);
    }
    

    并使 _data 只读(即不可变),一些聪明人说这很好。

所以问题是,你认为哪种方式更好,为什么?PS我使用了c#,但很可能适用于java。

4

4 回答 4

7

当我试图在我的应用程序设计中回答这样的问题时,我总是会考虑在他的应用程序中使用我的代码的人会期望什么。

以 C#DateTime类型为例。它是一个结构,因此是不可变的。当你要求

var today = DateTime.Now;
var tomorrow = today.AddDays(1);

如果您不知道它DateTime是不可变的,您会期待什么?没想到今天突然就是明天,那会是一片混乱。

至于您的示例,除非我另有决定,否则我会想象仅使用计算器的一个实例处理数字。这是有道理的,对吧?当我写一个方程时,我不会把每个表达式都写在新的一行上。我把它连同一个结果一起写出来,然后我跳到下一行以分离关注点。

所以

var calc = new Calculator(1);
calc.Add(1);
calc.PrintCurrentValue(); // imaginary method for printing of a current value of equation

对我来说很有意义。

于 2013-11-11T14:38:11.747 回答
4

我倾向于假设流利的方法会返回这个。但是,您提出了一个关于可变性的好观点,这让我在测试时感到困惑。使用您的示例,我可以执行以下操作:

var calc = new Calculator(0);
var newCalc = calc.Add(1).Add(2).Mult(3);
var result = calc.Add(1);

在阅读代码时,我想很多人会假设结果会1像他们看到的那样 calc + 1。当然,对于可变的流利系统,答案会随着Add(1).Add(2).Mult(3)应用的不同而不同。

不可变的流利系统更难实现,需要更复杂的代码。关于不变性的好处是否超过了实现它们所需的工作,这似乎是一个非常主观的事情。

于 2013-11-07T17:14:36.140 回答
3

如果不是为了类型推断,人们可以通过实现 API 中定义的不可变FluentThing类以及另一个FluentThingInternalUseOnly支持扩展转换为FluentThing. Fluent 成员 onFluentThing将构造一个新实例,FluentThingInternalUseOnly并将后一种类型作为其返回类型;的成员FluentThingInternalUseOnly将对 . 进行操作并返回this.

如果有人说FluentThing newThing = oldFluentThing.WithThis(4).WithThat(3).WithOther(57);,这个WithThis方法将构造一个新的FluentThingInternalUseOnly. 相同的实例将由 and 修改和WithThat返回WithOther;然后它将其中的数据复制到一个新FluentThing的,其引用将存储在newThing.

这种方法的主要问题是,如果有人说dim newThing = oldFluentThing.WithThis(3);, thennewThing不会持有对 immutable 的引用FluentThing,而是 mutable FluentThingInternalUseOnly,并且该事物将无法知道对它的引用已被持久化。

从概念上讲,需要一种FluentThingInternalUseOnly足够公开的方式,以便它可以用作公共函数的返回类型,但又不能公开到允许外部代码声明其类型的变量。不幸的是,我不知道有什么方法可以做到这一点,尽管可能有一些涉及Obsolete()标签的技巧是可能的。

否则,如果被操作的对象很复杂但操作很简单,那么最好的办法就是让流畅的接口方法返回一个对象,该对象包含对调用它的对象的引用以及关于什么的信息应该对该对象进行 [链接流畅的方法将有效地构建一个链表] 以及对已应用所有适当更改的对象的延迟评估引用。如果调用newThing = myThing.WithBar(3).WithBoz(9).WithBam(42)了 ,则在每一步都会创建一个新的包装对象,并且第一次尝试将其newThing用作事物将必须构造一个Thing应用了三个更改的实例,但原始对象myThing将保持不变,它会只需要创建一个新实例Thing而不是三个。

于 2013-11-12T19:59:26.880 回答
2

我想这一切都取决于你的用例。

大多数情况下,当我使用 Builder 时,它是由单线程来操作可变数据的。因此,返回 this 是首选,因为没有在任何地方返回新实例的额外开销和内存。

但是,我的许多构建器都有一个copy()方法,当我需要支持您的“专业第二”用例时,它会返回一个具有当前相同值的新实例

于 2013-11-07T16:49:14.287 回答