当涉及到具有大量可选参数的函数时，惯例是什么？答案

【问题标题】：What's the convention when it comes to functions with a lot of optional parameters?当涉及到具有大量可选参数的函数时，惯例是什么？
【发布时间】：2019-05-02 15:46:12
【问题描述】：

我有一个简单的 HttpsGet 函数，它接受大约 20 个可选参数。

现在我正在考虑在让每个参数可选和让用户创建他们将与函数一起使用的自定义选项对象之间。创建 200 个重载是不可能的。

使函数对其他用户可读和易于使用的最佳方法是什么？我错过了另一个解决方案吗？

为了便于阅读，这里是代码的简化版本。

static List<Assignments> GetAllAssignments([Optional] string levels, [Optional] string passed, [Optional] stringresurrected)
{               
    var json = Get($"assignments?{levels}&{passed}&{resurrected}");
    var assignments = JsonConvert.DeserializeObject<CollectionResponse<Assignments>>(json).Data;
    return assignments;            
}

【问题讨论】：

您可以将具有可为空属性的对象作为参数传递吗？
我会担心一个有 20 个可选参数的方法，无论它是在内部调用还是通过 HTTP 调用。如果一个调用可以传递 10 个参数，而另一个调用可以传递 10 个不同的参数，那么很难想象它们是如何做同一件事的。对于开发人员来说，这种方法可能会很复杂且难以查看。也许简化的一种方法是考虑调用者可能包含不同参数的场景，并为这些场景创建更具体的方法。
"我有一个简单的 HttpsGet 函数，它接受大约 20 个可选参数。" 一个有 20 个可选参数的函数绝非简单...... ;-)
@ScottHannen 我已经为这种情况制作了单独的方法，我提到的 ~20 是剩余的。如果用户希望查看未隐藏、未通过、存在于 7 到 16 级之间的某个位置并且在 7 月 4 日之后更新的作业，我无法决定他们是否应该这样做。

标签： c# conventions optional-parameters

【解决方案1】：

通常最好有一个“选项对象”来传递它而不是单个值。否则调用者很容易传递错误的值。

static List<LevelProgression> GetLevelProgressions(LevelProgressionOptions options) 
{ 
}

选项可能如下所示

public class LevelProgressionOptions
{
    public LevelProgressionOptions()
    {
        // Set any default values
        SomeProperty = 1;
    }

   public int SomeProperty { get; set; }
   public string AnotherOption { get; set; }
   //  other values omitted
}

【讨论】：