接口中的重载方法答案

【问题标题】：Overloaded methods in interface接口中的重载方法
【发布时间】：2011-06-15 15:51:38
【问题描述】：

我今天的问题：接口中的重载方法不好吗？你知道，“如果你不在乎就省略参数，我们会找出默认值”这种重载方法。像这样：

void Add(object item); 
void Add(object item, bool shouldDoSomething); 
void Add(object item, bool shouldDoSomething, IUltraObscureDeviceContext context);

在这种情况下，我倾向于认为只有后者属于一个接口，而其他的应该在它之上的抽象类中实现。但话又说回来，我不确定。

此外，有时您只是希望不同的重载执行稍微不同的工作（如果不应该使用重载方法，请在此阻止我）。或者有时你不能只用空值代替某些参数，如果某些参数为空，你希望抛出异常。在这种情况下我不应该使用重载吗？

所以基本上我正在寻找一些关于接口中的重载方法与实现这些接口的抽象类中的重载方法等方面的指南。提前致谢

【问题讨论】：

如果您提供的合同承诺提供此方法的 3 个版本，那么您应该包含这些重载。
@Kirk：六个中的一个，六个。真正的问题是它们是否应该被默认在界面中，而不是如何表达这些默认值。
@Kirk：因为默认参数不是什么灵丹妙药，现在意味着重载已经过时。例如，默认值必须是常量，也许重载会将变量传递给第二个或第三个重载。仅仅因为你有一个闪亮的新玩具并不意味着在任何地方都可以使用它。
@所有默认爱好者：blogs.infosupport.com/blogs/ernow/archive/2010/04/03/…
@Stook：直截了当的估计：如果每个人都阅读规范，stackoverflow 可能会减少一半以上的服务器、磁盘和带宽。

标签： c# oop interface c#-3.0

【解决方案1】：

如果默认值取决于方法调用的接收者，请将它们声明为接口方法。

如果默认值只是与接收者无关的默认值，则创建各种缩减参数列表重载作为扩展方法，并让实现者不必自己提供所有重载。

如果您正在处理某种具体的 80/20 规则异常，其中独立于实现的默认值几乎但不完全总是足够的，那么您有几个选项，其中没有一个有那么好吗：

就好像它们总是不同的一样处理它，将它们声明为接口方法，并在任何地方重新实现它们。不是很干燥。
就好像它们总是不同的一样处理它，将它们声明为接口方法，并继承一个提供 80% 默认实现的基类。有点笨拙，如果你唯一的基类插槽已经被占用，那就不好了。
创建另一个包含这些特定方法的接口。声明与原始接口匹配签名的扩展方法。在扩展方法中，as-将this 参数转换为新的接口类型，如果匹配，则在那里调用它，否则填写库存默认值。非常时髦，依赖于动态转换，因此在内部循环中不是很好，但它可以将默认值与实现者和调用者分离，而不会牺牲不能采用“默认默认值”的实现者的灵活性。

【讨论】：

最后一个选项确实很时髦，但听起来像是解决坏问题的好方法。总体上可靠的答案，谢谢。
如何让接口包含一个位掩码枚举参数，该参数指示指定了哪些其他参数，并让独立于实现的包装器在额外参数中使用适当的值调用“真实”例程？如果我有我的 druthers，就会有一种自动执行此操作的方法，但即使没有自动机制，它仍然是一个好方法。

【解决方案2】：

IMO 如果接口/合同明确说明，应该没有问题。然而，目标是在暴露界面和隐藏细节时简化事情。这就是可选参数派上用场的地方。像 Python 这样的完美面向对象的语言甚至没有重载 AFAIK

【讨论】：

其他完全适合的面向对象语言，如 Objective-C 没有接口（ObjC 有一些相关的协议），这也可以解决这个问题。

【解决方案3】：

如果接口的设计允许，接口中的重载方法可能没问题。我个人从来不需要这样做。

我不会在界面中定义默认参数值。这是实现选择浮出水面的类的实现细节。

您对重载有不同的实现发表评论......

不要那样做。将这些重载方法的实现视为调用一个方法，该方法的所有参数都定义了一些默认值。这就是您的代码的用户所期望的。

如果您需要不同的行为，请使用多态性。这就是它的用途。

【讨论】：

多态不会在一个实例中为您提供两种实现。我想，这就是有不同名称的方法
是的，间接我说的是实现类应该是不同的，而不是通过让不同的重载实现不同的东西来混淆事物，而是使用多态性。