c# - 什么时候应该使用 params Object[] 与 Dictionary？

Question

我将一个 API 定义为一个接口(interface)，我们称之为 IFoo我想定义一个方法 Bar()

这个方法Bar()将采用一个必需的参数，然后是任意数量的其他参数。这些其他参数的解释将取决于 IFoo 的实现者。

对于这种情况，使用 params 定义我的接口(interface)是否更合适？或使用 Dictionary<String, Object>例如

public interface IFoo
{
   bool Bar(String id, params Object[] params);
}

或者

public interface IFoo
{
   bool Bar(String id, Dictionary<String, Object> params);
}

似乎前者更容易让用户调用，但后者的意图更明确，因为对于前者，您必须以特定顺序指定参数以便实现正确解释它们，而对于后者您实际上是在执行命名参数。

所以问题:

• 我应该使用哪种形式(为什么？)- 其中一种被认为是优于另一种的最佳做法吗？
• 我应该注意一种风格与另一种风格相比有什么具体优势吗？其中之一是否被视为代码味道？
• 是否有替代模式可以以不同/更好的方式实现相同的目标？

据我所知named parameters在 .Net 4.0 中，但此代码需要在 .Net 3.5 上可编译，因此不能使用任何 .Net 4.0+ 功能

编辑

只是为了添加更多关于我的 IFoo 的细节和 Bar()方法实际上是代表，因为有人问。

IFoo代表一些存储子系统和Bar()实际上是一个创建操作。取决于存储子系统 Bar()可能不需要除 ID 以外的任何参数，也可能需要很多参数。

编辑2

因此，为了回应@Kirk Woll 的评论和@Fernando 的回答，这里有更多信息。

我可能永远不会调用 IFoo.Bar()我自己，这个界面是开源框架的一部分。第三方开发者将实现 IFoo最终用户将调用它的特定实例，具有 IFoo 的意义根本上是为了让用户更容易在存储子系统之间迁移他们的应用程序，因为他们可以尽可能地针对接口(interface)而不是特定实现进行编码。

在最简单的情况下，底层存储子系统只有一种存储形式，因此除了 ID 之外不需要任何参数。在复杂的情况下，存储子系统可以允许多种类型的存储，并且每种类型的存储可以允许任意复杂的配置参数集，例如索引大小、持久性、事务行为、索引策略、安全性和 ACL 考虑因素等。

我同意@Fernando 的观点，也许更多的多态性可能是有意义的，也许多态性与泛型和类型限制相结合可能是最好的，例如

public interface IFoo
{
  bool Bar<T>(T parameters) where T : IBarConfig;
}

public interface IBarConfig
{
  String ID { get; set; }
}

然后像这样实现:

public class MyFoo
{
  bool Bar<T>(T config) where T : MyBarConfig
  {
    //Implementation
  }
}

public class MyBarConfig : IBarConfig
{
  public String ID { get; set; }

  public long IndexSegmentSize { get; set; }

  //Etc...
}

这超出了我的脑海，所以不确定定义 Bar() 是否真的合法在MyFoo具有与它实现的接口(interface)不同的类型限制？

Answer 1

您需要决定是否需要搜索或能够从参数集合/数组中检索对象。

使用 Object[] params 时, 对象上没有索引。您需要遍历整个集合以找到一个项目(通过其键)。

使用 Dictionary<String, Object> 时，您的对象由它们的键索引，并且它总是很容易通过键搜索/查询。

根据您的需要，您需要决定您的方法。

字典搜索速度更快，但创建索引会产生开销。