如何避免API设计中的“参数过多”问题？

我有这个API函数：

public ResultEnum DoSomeAction(string a, string b, DateTime c, OtherEnum d, 
     string e, string f, out Guid code)

我不喜欢 因为参数顺序变得不必要地重要。添加新字段变得越来越困难。很难看到正在传递的内容。很难将方法重构为较小的部分，因为这会带来在子函数中传递所有参数的另一项开销。代码更难读。

我想到了一个最明显的想法：让一个对象封装数据并将其传递，而不是一个个地传递每个参数。这是我想出的：

public class DoSomeActionParameters
{
    public string A;
    public string B;
    public DateTime C;
    public OtherEnum D;
    public string E;
    public string F;        
}

这使我的API声明减少为：

public ResultEnum DoSomeAction(DoSomeActionParameters parameters, out Guid code)

真好 看起来很无辜，但实际上我们进行了巨大的更改：我们引入了可变性。因为我们之前所做的实际上是在堆栈上传递一个匿名的不可变对象：函数参数。现在我们创建了一个非常可变的新类。我们创建了一种操作调用者状态的功能。糟透了。现在我希望我的对象是不变的，我该怎么办？

public class DoSomeActionParameters
{
    public string A { get; private set; }
    public string B { get; private set; }
    public DateTime C { get; private set; }
    public OtherEnum D { get; private set; }
    public string E { get; private set; }
    public string F { get; private set; }        

    public DoSomeActionParameters(string a, string b, DateTime c, OtherEnum d, 
     string e, string f)
    {
        this.A = a;
        this.B = b;
        // ... tears erased the text here
    }
}

如您所见，我实际上重新创建了最初的问题：参数太多。显然，这不是要走的路。我该怎么办？实现这种不变性的最后一个选择是使用如下所示的“只读”结构：

public struct DoSomeActionParameters
{
    public readonly string A;
    public readonly string B;
    public readonly DateTime C;
    public readonly OtherEnum D;
    public readonly string E;
    public readonly string F;        
}

这使我们可以避免构造函数使用太多参数并实现不变性。实际上，它解决了所有问题（参数订购等）。然而：

• 每个人（包括FXCop和Jon Skeet）都同意 公开公共领域是不好的。
• 埃里克·利珀特（Eric Lippert）等人说，依靠只读字段实现不变性是一个谎言。

那时候我感到困惑，决定写这个问题：C＃中最简单的方法是在不引入可变性的情况下避免“参数过多”的问题？可以使用只读结构来实现此目的，但又不会有不好的API设计吗？

说明：

• 请假设没有违反单一责任原则。在我的原始情况下，该函数只是将给定的参数写入单个DB记录。
• 我没有在寻找给定功能的特定解决方案。我正在寻求针对此类问题的通用方法。我对解决“参数过多”问题特别感兴趣，而又不会引入可变性或糟糕的设计。

更新

此处提供的答案具有不同的优点/缺点。因此，我想将其转换为社区Wiki。我认为每个带有代码示例和优点/缺点的答案都将为将来解决类似问题提供很好的指南。我现在正试图找出方法。

框架中包含的一种样式通常类似于将相关参数分组到相关类中（但又存在可变性问题）：

var request = new HttpWebRequest(a, b);
var service = new RestService(request, c, d, e);
var client = new RestClient(service, f, g);
var resource = client.RequestRestResource(); // O params after 3 objects

结合使用构建器和特定于域的语言样式的API--Fluent接口。该API较为冗长，但具有智能感知功能，可以快速输入并易于理解。

public class Param
{
        public string A { get; private set; }
        public string B { get; private set; }
        public string C { get; private set; }


  public class Builder
  {
        private string a;
        private string b;
        private string c;

        public Builder WithA(string value)
        {
              a = value;
              return this;
        }

        public Builder WithB(string value)
        {
              b = value;
              return this;
        }

        public Builder WithC(string value)
        {
              c = value;
              return this;
        }

        public Param Build()
        {
              return new Param { A = a, B = b, C = c };
        }
  }


  DoSomeAction(new Param.Builder()
        .WithA("a")
        .WithB("b")
        .WithC("c")
        .Build());

您所拥有的信息可以肯定地表明所讨论的类违反了“ 单一职责原则”，因为它具有过多的依赖项。寻找将这些依赖项重构为Facade依赖项群集的方法。

只需将参数数据结构从a更改class为a struct，就可以了。

public struct DoSomeActionParameters 
{
   public string A;
   public string B;
   public DateTime C;
   public OtherEnum D;
   public string E;
   public string F;
}

public ResultEnum DoSomeAction(DoSomeActionParameters parameters, out Guid code) 

现在，该方法将获得其自己的结构副本。方法无法观察到对参数变量所做的更改，调用者也无法观察到对变量进行方法更改。实现隔离而不会一成不变。

优点：

• 最容易实施
• 基本机制中行为的最小变化

缺点：

• 不变性并不明显，需要开发人员注意。
• 不必要的复制以保持不变性
• 占用堆栈空间

如何在数据类中创建构建器类。数据类会将所有设置器设为私有，只有构建器才能设置它们。

public class DoSomeActionParameters
    {
        public string A { get; private set; }
        public string B  { get; private set; }
        public DateTime C { get; private set; }
        public OtherEnum D  { get; private set; }
        public string E  { get; private set; }
        public string F  { get; private set; }

        public class Builder
        {
            DoSomeActionParameters obj = new DoSomeActionParameters();

            public string A
            {
                set { obj.A = value; }
            }
            public string B
            {
                set { obj.B = value; }
            }
            public DateTime C
            {
                set { obj.C = value; }
            }
            public OtherEnum D
            {
                set { obj.D = value; }
            }
            public string E
            {
                set { obj.E = value; }
            }
            public string F
            {
                set { obj.F = value; }
            }

            public DoSomeActionParameters Build()
            {
                return obj;
            }
        }
    }

    public class Example
    {

        private void DoSth()
        {
            var data = new DoSomeActionParameters.Builder()
            {
                A = "",
                B = "",
                C = DateTime.Now,
                D = testc,
                E = "",
                F = ""
            }.Build();
        }
    }

我不是C＃程序员，但我相信C＃支持命名参数：（F＃可以，并且C＃在很大程度上适合于此类事情）它可以： http //msdn.microsoft.com/zh-cn/library/dd264739 .aspx＃Y342

因此，调用您的原始代码将变为：

public ResultEnum DoSomeAction( 
 e:"bar", 
 a: "foo", 
 c: today(), 
 b:"sad", 
 d: Red,
 f:"penguins")

这样就不需要花费更多的空间/思想来创建对象并拥有所有的好处，因为您根本没有改变过这个系统中正在发生的一切。您甚至不必重新编码即可表明参数已命名

编辑：这是我发现的一篇文章。 http://www.globalnerdy.com/2009/03/12/default-and-named-parameters-in-c-40-sith-lord-in-training/ 我应该提到C＃4.0支持命名参数，而3.0没有

为什么不仅仅制作一个强制不变性的接口（即仅使用吸气剂）？

从本质上讲，这是您的第一个解决方案，但是您可以强制该函数使用接口来访问参数。

public interface IDoSomeActionParameters
{
    string A { get; }
    string B { get; }
    DateTime C { get; }
    OtherEnum D { get; }
    string E { get; }
    string F { get; }              
}

public class DoSomeActionParameters: IDoSomeActionParameters
{
    public string A { get; set; }
    public string B { get; set; }
    public DateTime C { get; set; }
    public OtherEnum D { get; set; }
    public string E { get; set; }
    public string F { get; set; }        
}

并且函数声明变为：

public ResultEnum DoSomeAction(IDoSomeActionParameters parameters, out Guid code)

优点：

• 没有像这样的堆栈空间问题 struct解决方案
• 使用语言语义的自然解决方案
• 不变性显而易见
• 灵活（消费者可以根据需要使用其他类别）

缺点：

• 一些重复的工作（两个不同实体中的相同声明）
• 开发人员必须猜测这DoSomeActionParameters是可以映射到的类IDoSomeActionParameters

我知道这是一个老问题，但是我认为我不得不接受我的建议，因为我不得不解决相同的问题。现在，不可否认，我的问题与您的问题稍有不同，因为我还有其他要求，即不希望用户自己构造该对象（数据的所有混合都来自数据库，因此我可以在内部阻止所有构造）。这使我可以使用私有构造函数和以下模式；

    public class ExampleClass
    {
        //create properties like this...
        private readonly int _exampleProperty;
        public int ExampleProperty { get { return _exampleProperty; } }

        //Private constructor, prohibiting construction outside of this class
        private ExampleClass(ExampleClassParams parameters)
        {                
            _exampleProperty = parameters.ExampleProperty;
            //and so on... 
        }

        //The object returned from here will be immutable
        public ExampleClass GetFromDatabase(DBConnection conn, int id)
        {
            //do database stuff here (ommitted from example)
            ExampleClassParams parameters = new ExampleClassParams()
            {
                ExampleProperty = 1,
                ExampleProperty2 = 2
            };

            //Danger here as parameters object is mutable

            return new ExampleClass(parameters);    

            //Danger is now over ;)
        }

        //Private struct representing the parameters, nested within class that uses it.
        //This is mutable, but the fact that it is private means that all potential 
        //"damage" is limited to this class only.
        private struct ExampleClassParams
        {
            public int ExampleProperty { get; set; }
            public int AnotherExampleProperty { get; set; }
            public int ExampleProperty2 { get; set; }
            public int AnotherExampleProperty2 { get; set; }
            public int ExampleProperty3 { get; set; }
            public int AnotherExampleProperty3 { get; set; }
            public int ExampleProperty4 { get; set; }
            public int AnotherExampleProperty4 { get; set; } 
        }
    }

您可以使用Builder风格的方法，尽管根据您DoSomeAction方法的复杂性，这可能是一个重量级的任务。遵循以下原则：

public class DoSomeActionParametersBuilder
{
    public string A { get; set; }
    public string B { get; set; }
    public DateTime C { get; set; }
    public OtherEnum D { get; set; }
    public string E { get; set; }
    public string F { get; set; }

    public DoSomeActionParameters Build()
    {
        return new DoSomeActionParameters(A, B, C, D, E, F);
    }
}

public class DoSomeActionParameters
{
    public string A { get; private set; }
    public string B { get; private set; }
    public DateTime C { get; private set; }
    public OtherEnum D { get; private set; }
    public string E { get; private set; }
    public string F { get; private set; }

    public DoSomeActionParameters(string a, string b, DateTime c, OtherEnum d, string e, string f)
    {
        A = a;
        // etc.
    }
}

// usage
var actionParams = new DoSomeActionParametersBuilder
{
    A = "value for A",
    C = DateTime.Now,
    F = "I don't care for B, D and E"
}.Build();

result = foo.DoSomeAction(actionParams, out code);

除了manji响应之外，您可能还希望将一个操作拆分为几个较小的操作。比较：

 BOOL WINAPI CreateProcess(
   __in_opt     LPCTSTR lpApplicationName,
   __inout_opt  LPTSTR lpCommandLine,
   __in_opt     LPSECURITY_ATTRIBUTES lpProcessAttributes,
   __in_opt     LPSECURITY_ATTRIBUTES lpThreadAttributes,
   __in         BOOL bInheritHandles,
   __in         DWORD dwCreationFlags,
   __in_opt     LPVOID lpEnvironment,
   __in_opt     LPCTSTR lpCurrentDirectory,
   __in         LPSTARTUPINFO lpStartupInfo,
   __out        LPPROCESS_INFORMATION lpProcessInformation
 );

和

 pid_t fork()
 int execvpe(const char *file, char *const argv[], char *const envp[])
 ...

对于那些不了解POSIX的人来说，创建孩子就像这样简单：

pid_t child = fork();
if (child == 0) {
    execl("/bin/echo", "Hello world from child", NULL);
} else if (child != 0) {
    handle_error();
}

每个设计选择都代表着可能进行的操作之间的权衡。

PS。是的-与构建器类似-仅相反（即在被叫方而不是呼叫方）。在这种特定情况下，它可能比构造器更好，也可能更好。

这与Mikeys略有不同，但是我想做的是使整个事情写得尽可能少

public class DoSomeActionParameters
{
    readonly string _a;
    readonly int _b;

    public string A { get { return _a; } }

    public int B{ get { return _b; } }

    DoSomeActionParameters(Initializer data)
    {
        _a = data.A;
        _b = data.B;
    }

    public class Initializer
    {
        public Initializer()
        {
            A = "(unknown)";
            B = 88;
        }

        public string A { get; set; }
        public int B { get; set; }

        public DoSomeActionParameters Create()
        {
            return new DoSomeActionParameters(this);
        }
    }
}

DoSomeActionParameters可能是不变的，并且不能直接创建，因为其默认构造函数是private

初始化程序不是一成不变的，而只是一个传输

用法利用了初始化器上的初始化器（如果您不满意的话），并且我可以在初始化器默认构造函数中使用默认值

DoSomeAction(new DoSomeActionParameters.Initializer
            {
                A = "Hello",
                B = 42
            }
            .Create());

这些参数在这里是可选的，如果您需要一些参数，可以将它们放在Initializer的默认构造函数中

验证可以在Create方法中进行

public class Initializer
{
    public Initializer(int b)
    {
        A = "(unknown)";
        B = b;
    }

    public string A { get; set; }
    public int B { get; private set; }

    public DoSomeActionParameters Create()
    {
        if (B < 50) throw new ArgumentOutOfRangeException("B");

        return new DoSomeActionParameters(this);
    }
}

所以现在看起来

DoSomeAction(new DoSomeActionParameters.Initializer
            (b: 42)
            {
                A = "Hello"
            }
            .Create());

我知道还是有点怪异，但还是要尝试一下

编辑：将create方法移动到parameter对象中的静态对象，并添加一个传递初始化程序的委托，以消除调用中的某些怪异现象

public class DoSomeActionParameters
{
    readonly string _a;
    readonly int _b;

    public string A { get { return _a; } }
    public int B{ get { return _b; } }

    DoSomeActionParameters(Initializer data)
    {
        _a = data.A;
        _b = data.B;
    }

    public class Initializer
    {
        public Initializer()
        {
            A = "(unknown)";
            B = 88;
        }

        public string A { get; set; }
        public int B { get; set; }
    }

    public static DoSomeActionParameters Create(Action<Initializer> assign)
    {
        var i = new Initializer();
        assign(i)

        return new DoSomeActionParameters(i);
    }
}

所以通话现在看起来像这样

DoSomeAction(
        DoSomeActionParameters.Create(
            i => {
                i.A = "Hello";
            })
        );

使用该结构，但具有公共属性，而不是公共字段：

•每个人（包括FXCop和Jon Skeet）都同意公开公共场所是有害的。

Jon和FXCop会很满意，因为您公开的是属性而不是字段。

•埃里克·利珀特（Eric Lippert）等人说，依靠只读字段实现不变性是一个谎言。

埃里克（Eric）将很满意，因为使用属性可以确保该值仅设置一次。

    private bool propC_set=false;
    private date pC;
    public date C {
        get{
            return pC;
        }
        set{
            if (!propC_set) {
               pC = value;
            }
            propC_set = true;
        }
    }

一个半不变的对象（可以设置但不能更改值）。适用于值和引用类型。

当我遇到相同问题时，我在项目中使用了萨缪尔（Samuel）答案的一种变体：

class MagicPerformer
{
    public int Param1 { get; set; }
    public string Param2 { get; set; }
    public DateTime Param3 { get; set; }

    public MagicPerformer SetParam1(int value) { this.Param1 = value; return this; }
    public MagicPerformer SetParam2(string value) { this.Param2 = value; return this; }
    public MagicPerformer SetParam4(DateTime value) { this.Param3 = value; return this; }

    public void DoMagic() // Uses all the parameters and does the magic
    {
    }
}

并使用：

new MagicPerformer().SeParam1(10).SetParam2("Yo!").DoMagic();

在我的情况下，参数是有意修改的，因为setter方法不允许所有可能的组合，而只公开了它们的常见组合。那是因为我的一些参数相当复杂，并且为所有可能的情况编写方法将是困难且不必要的（很少使用疯狂的组合）。