流畅的界面设计和代码味道

Question

public class StepClause
{
    public NamedStepClause Action1() {}

    public NamedStepClause Action2() {}
}

public class NamedStepClause : StepClause
{
    public StepClause Step(string name) {}
}

基本上，我希望能够做这样的事情：

var workflow = new Workflow().Configure()
    .Action1()
    .Step("abc").Action2()
    .Action2()
    .Step("def").Action1();

因此，有些“步骤”被命名，有些则没有。

我不喜欢的是 StepClause 了解其派生类 NamedStepClause。

我尝试了一些方法来让我感觉更舒服。 我尝试将内容移至接口，但问题只是从具体转移到接口 - INamedStepClause 仍然需要从 IStepClause 派生，并且 IStepClause 需要返回 INamedStepClause 才能调用 Step()。 我还可以使 Step() 成为完全独立类型的一部分。那么我们就不会遇到这个问题，并且我们会遇到：

var workflow = new Workflow().Configure()
    .Step().Action1()
    .Step("abc").Action2()
    .Step().Action2()
    .Step("def").Action1();

没关系，但如果可能的话，我想让步骤命名可选。

我在此处找到了另一篇文章，它看起来很有趣并且很有前途。 你有什么意见？我认为原来的解决方案是完全不可接受的，是吗？

顺便说一句，这些操作方法将采用谓词和函子，我认为我不想采用额外的参数来命名那里的步骤。

对我来说，这一切的重点是仅在一处定义这些操作方法。因此，引用链接中使用泛型和扩展方法的解决方案似乎是迄今为止最好的方法。

Answer 1

我给你两个选择。

选项 A

var a = new A.NamedStepClause();

a.Action1()
    .Step("abc").Action2()
    .Action2()
    .Step("def").Action1();


namespace A
{
    public class StepClause<SC> where SC : StepClause<SC>
    {
        public SC Action1() { return null; }
        public SC Action2() { return null; }
    }

    public class NamedStepClause : StepClause<NamedStepClause>
    {
        public NamedStepClause Step(string name) { return null; }
    }
}

选项 B

var b = new B.StepClause();

b.Action1()
    .Step("abc").Action2()
    .Action2()
    .Step("def").Action1();

namespace B
{
    public class StepClause
    {
        public StepClause Action1() { return null; }
        public StepClause Action2() { return null; }
    }

    public static class StepClauseExtensions
    {
        public static StepClause Step(this StepClause @this, string name)
        { return null; }
    }
}

两个选项都会编译并为您提供您正在寻找的流畅界面。我更倾向于选择选项 A，因为它可以让您了解类的内部运作方式。使用扩展方法意味着您可能需要对您的类进行某种外部访问，从而破坏封装。

祝你好运！